Microservices and Distributed Systems
Service boundaries, data ownership, failure handling, and when a monolith is the better choice.
This program is planned and not scheduled yet. No date, price or cohort has been announced. If you register interest, we contact you when it is scheduled or to discuss an individual format.
Objective
The program teaches the core difficulties of distributed systems inside a real decision framework: where to draw service boundaries, how to decide who owns which data, and how to live with network failure. It also states openly that microservices are not always the answer and analyses the cases where a modular monolith is the better choice.
Who it's for
- Engineers with solid Spring Boot experience who work or will work on multi-service systems
- Senior candidates who take part in decisions about splitting a monolith
- Backend developers who must reason about the effect of their service on the rest of the system
- People moving towards an architecture role
Who it's not for
- Anyone still learning Spring Boot and database fundamentals: start with the Java Backend Career Track
- Anyone who only wants Kubernetes administration: the program covers only the concepts needed
- Anyone who treats microservices as the ready answer to every problem: the program questions that idea
Prerequisites
- Experience writing real services with Spring Boot
- Understanding of transactions, indexes and SQL
- REST API design and HTTP basics
- Running containers with Docker
- A general idea of what a message broker is
What you will be able to do
What you will be able to do
- Propose and justify a service split based on domain boundaries
- Build a data model in which every piece of data has a single owner
- Choose between synchronous and asynchronous communication for a concrete scenario
- Configure timeouts, retries, backoff and circuit breakers correctly together
- Implement a multi-service operation as a saga with compensation logic
- Explain the effect of eventual consistency on user experience
- Follow a request across services with distributed tracing
- Package a service in a container and describe it with Kubernetes concepts (deployment, probes, resource limits)
No education program can guarantee employment or a promotion.
Curriculum
Curriculum
- 01
Service boundaries
Learning to split services by business capability rather than by technical layer.
- Bounded context and the basics of domain-driven design
- Boundary signals: change frequency and team ownership
- Kinds of coupling and the distributed-monolith trap
- Gradual decomposition with the strangler approach
- The modular monolith as an alternative
Hands-on lab: Propose a service split for a given monolithic ordering system and compare two alternatives in a trade-off table.
- 02
Data ownership
Answering how queries and reports work once each service owns its data.
- Database per service and the risks of a shared database
- Data duplication and read models
- API composition and an introduction to CQRS
- Living without cross-service referential integrity
- Data migration and schema ownership
Hands-on lab: Separate two services that share a table: draw the ownership boundary and write a staged plan to move the data.
- 03
Synchronous and asynchronous communication
Comparing the consequences of choosing REST, gRPC or messaging.
- REST versus gRPC: contract and performance differences
- Messaging and event-based interaction
- Temporal coupling and availability arithmetic
- Contract tests (consumer-driven contracts)
- The role of an API gateway and a BFF
Hands-on lab: Build the same workflow synchronously and asynchronously and compare availability and latency.
- 04
Failure handling
The network is unreliable; we design the system to respond to that properly.
- Timeout budgets and cascading failure
- Retries, exponential backoff and jitter
- Circuit breakers, bulkheads and load shedding
- Idempotency keys
- An introduction to chaos experiments
Hands-on lab: Inject faults into a service and compare system behaviour with and without timeouts and a circuit breaker.
- 05
Sagas and consistency models
Working with compensating flows and eventual consistency instead of distributed transactions.
- Strong versus eventual consistency
- Sagas: choreography and orchestration
- Compensating actions and steps that cannot be undone
- Transactional outbox
- Showing partial state to the user
Hands-on lab: Build a saga across order, payment and warehouse services and verify compensation on payment failure with tests.
- 06
Distributed tracing and observability
Making visible what happens when one request crosses several services.
- Traces, spans and context propagation
- Instrumentation with OpenTelemetry
- Correlation IDs across services
- Service maps and dependency analysis
- SLO-based alerting
Hands-on lab: Set up OpenTelemetry across a three-service flow and locate the source of a slowdown from the trace.
- 07
Deployment: containers and Kubernetes concepts
The concepts needed to package and run a service, without going into cluster administration.
- Docker image layers and small images
- Deployment, Service and ConfigMap concepts
- Liveness and readiness probes
- Resource requests/limits and JVM memory alignment
- Rolling updates and rollback
Hands-on lab: Containerise a service, write a deployment manifest and observe the consequences of misconfigured probes.
- 08
When a modular monolith is better
An honest assessment of the real cost of choosing microservices, and of the alternatives.
- The cost of operational complexity
- Team size and Conway's law
- Boundary discipline inside a modular monolith
- Writing a decision record (ADR)
Hands-on lab: For a given company scenario, compare monolith, modular monolith and microservices in ADR format and write the decision.
Practice assignments
- A service-split proposal with a trade-off table
- A resilience test with fault injection
- A saga implementation with a compensation test
- A trace-based slowdown investigation
- An architecture decision record (ADR)
Portfolio deliverables
- A three-service sample system with an architecture diagram
- A result report of the resilience test
- A saga flow with compensation tests
- An ADR justifying a monolith versus microservices decision
How learning is assessed
- Defense of the architecture design
- Mentor code review
- A written analysis of a failure scenario
- Feedback on ADRs
Tools and technologies
- Spring Boot
- Docker
- Kubernetes (conceptual level)
- OpenTelemetry
- Resilience4j
- PostgreSQL
- Kafka or RabbitMQ
- gRPC
- Grafana
Level progression
- Before
- Before: Enterprise Spring Boot, or strong middle-level experience with Spring Boot.
- After
- After: Kafka and Event-Driven Architecture, System Design.
- Length and format
- Length and format are not set yet; the program is planned and not scheduled.
Frequently asked questions
Frequently asked questions
Is this program available now?
No. It is planned and not scheduled yet. No dates or prices have been announced. You can register interest or request a consultation.
Do I need to know Kubernetes?
Not in advance. The program explains only concepts such as deployments, probes and resource limits; cluster administration is not covered.
Does the program promote microservices?
No. The value and the cost of microservices are discussed equally, and the cases where a modular monolith wins have their own module.
Is there a certificate or a job promise?
No. No certificate or outcome is promised. Evaluation takes the form of design defenses and mentor feedback and is a recommendation only.
Articles related to this program
- Cloud architectureCloud architecture basics for backend engineers
- Distributed systemsFailure handling in distributed systems
- DockerDocker for Java services
- Distributed systemsIdempotency patterns for safe retries
- MicroservicesDrawing microservice boundaries
- ObservabilityObservability: logs, metrics and traces