Microservices & System Design
A 16-week instructor-led program for working Java/backend engineers: architecture trade-offs, DDD, Kafka, outbox and sagas, PostgreSQL under load, Kubernetes, AWS Well-Architected, observability and AI-assisted engineering. You evolve one distributed system through the whole course and defend it with working code, ADRs, a load test and a failure scenario. This is a planned syllabus that may be adjusted to the group; there is no job guarantee.
- Duration
- 16 weeks
- Live sessions
- 2 per week, 90 minutes each
- Structure
- 4 phases
- Language
- Azerbaijani or English (per cohort)
- Weekly workload
- Plan for at least 6 hours of practice a week including labs
- How it ends
- An architecture defense with ADRs, a load test and a failure scenario
The system you build all course
One distributed system, sixteen weeks
You grow a ticketing platform step by step. Pick a pattern to see the problem it solves, how it fails and the week it is taught.
Problem
Writing the order and publishing the event must succeed together.
How it fails
The broker is down and the event is lost, or a duplicate message sends two notifications.
Taught in
Week 7
The diagram shows the course's training system (not a real company). Kubernetes labs run on a free local cluster (kind/k3d); AWS is taught without creating paid resources.
About the program
Who it is for
Java backend developers (junior+ and middle) and Java & Backend Engineering graduates who want to draw service boundaries, connect services reliably and justify system design decisions.
Prerequisites
- You write REST APIs with Spring Boot
- You have worked with SQL, transactions and JPA
- Git, tests and Docker basics
Technologies
- Java 21
- Spring Boot
- PostgreSQL, Flyway
- Kafka
- Outbox, sagas, CQRS
- OpenAPI, contract tests
- Resilience4j
- Redis
- OpenTelemetry, Micrometer
- Docker, CI/CD
- OAuth2/OIDC
How it is completed
- Phase checkpoints: two services with a context map and a contract test; an outbox, an idempotent consumer and a saga; a load test, traces, an SLO and a rollback plan
- Capstone: a service system you built, with a design document, ADRs, an incident scenario and a technical defense assessed with a rubric
Mentoring and feedback
Live sessions are instructor-led; every weekly assignment is reviewed against a 100-point rubric with written feedback. Each phase ends with a checkpoint, so weak areas show up early.
16 weeks
Week-by-week syllabus
This is the planned syllabus: order and depth may be adjusted to the group. It is not a job or title guarantee.
01 · Weeks 1–4
Architecture foundations
Phase goal: Start from quality attributes: learn when and how to split a system, protect contracts and run the database under load.
Week 1
Architecture, quality attributes and trade-offs
- Quality attributes: availability, latency, modifiability, cost
- Modular monolith vs microservices: when not to split
- ADRs and C4 diagrams
- The system we evolve all course: a distributed ticketing platform
Lab: Draw C4 context and container diagrams of the training monolith and write scenarios for two quality attributes.
Assignment: ADR: stay a monolith or extract one module — with reasoning and alternatives.
Week 2
Domain-driven design and service decomposition
- Ubiquitous language, bounded contexts, context maps
- Aggregates and invariants
- Data ownership: a database per service
- Incremental extraction with the strangler fig
Lab: Event storming: find the contexts, aggregates and data owners of the ticketing platform.
Assignment: A context map and a strangler-fig plan for extracting the first service.
Week 3
Service contracts: REST, gRPC and asynchronous communication
- Synchronous vs asynchronous: coupling and failure
- Contract-first with OpenAPI and gRPC
- Versioning and backward compatibility
- Consumer-driven contract tests and the API gateway
Lab: An OpenAPI contract for the extracted service, a gateway route and a contract test that guards it.
Assignment: Ship a new version without breaking the contract; show CI catching a breaking change.
Week 4
PostgreSQL at scale: queries, isolation and locks
- EXPLAIN ANALYZE and index design
- Isolation levels, locks and deadlocks
- Connection pooling (HikariCP) and exhaustion
- Zero-downtime migrations
Lab: Reproduce a slow query and a deadlock under load, measure them, then fix them.
Assignment: A performance report with before/after measurements and a reversible migration.
Checkpoint: ADRs, C4, a context map, a contract test and a measured performance fix.
02 · Weeks 5–8
Distributed data and events
Phase goal: Connect services through Kafka without losing or double-processing data, and choose consistency deliberately.
Week 5
Distributed systems fundamentals
- Replication and partitioning
- Consistency models and CAP misconceptions
- Delivery semantics and ordering
- Failure detection and coordination
Lab: Simulate network latency and a partition and observe how two replicas behave.
Assignment: A consistency-requirements table for each operation of the system, with reasoning.
Week 6
Kafka and event-driven systems
- Partitions, consumer groups, offsets and rebalancing
- Delivery guarantees and the idempotent producer
- Schema evolution and event contracts
- Retries, dead-letter topics and consumer lag
Lab: Failure lab: a slow consumer builds lag and triggers a rebalance storm — diagnose and fix.
Assignment: An event contract, a dead-letter policy and an alert threshold for lag.
Week 7
Outbox, idempotency and sagas
- The dual-write problem and the transactional outbox
- The idempotent consumer
- Sagas: choreography vs orchestration, compensation
- Alternatives to distributed transactions
Lab: An order → payment → seat reservation saga; no event is lost while the broker is down.
Assignment: Tests for the behaviour at every failure point and a saga state diagram.
Week 8
CQRS, event sourcing and caching
- Read models and showing eventual consistency to users
- Event sourcing: when it pays off and when it does not
- Redis caching strategies and invalidation
- Cache stampedes and consistency
Lab: Build a read model from events, rebuild it from scratch and measure a cache under load.
Assignment: ADR: use event sourcing or not — for one context of the system.
Checkpoint: An outbox, an idempotent consumer, a saga with compensation, a read model and the Kafka failure lab.
03 · Weeks 9–12
Cloud-native operations
Phase goal: Make the system resilient, deploy and debug it on Kubernetes, observe it and manage incidents.
Week 9
Resilience and performance
- Timeout budgets, retries and backoff with jitter
- Circuit breakers and bulkheads
- Backpressure, rate limiting and load shedding
- Load testing and bottleneck analysis
Lab: Failure lab: a slow dependency causes a retry storm — protect with Resilience4j and limits, prove it with k6.
Assignment: Load-test results, the reasoning behind the chosen limits and an incident report.
Week 10
Containers and Kubernetes I
- OCI images and a secure Dockerfile
- Kubernetes architecture: control plane, nodes, pods
- Deployments, Services, Ingress/Gateway
- ConfigMaps, Secrets, probes, requests and limits
Lab: Deploy the services to a local kind/k3d cluster and debug a broken probe (free, on your own machine).
Assignment: Manifests, the reasoning for resource limits and troubleshooting notes.
Week 11
Kubernetes II: releases, scaling and security
- Rolling updates, rollbacks and release strategies
- HPA and autoscaling
- Helm, namespaces and GitOps principles
- RBAC, network policies and cluster security
Lab: Failure lab: a misconfigured rollout — detect it, roll back and fix the Helm chart.
Assignment: A Helm chart, a network policy and a rollback runbook.
Week 12
Observability and production operations
- OpenTelemetry: traces, metrics, logs
- Prometheus, Grafana and alert design
- SLIs, SLOs and error budgets
- Incident management, RCA and runbooks
Lab: Failure lab: a latency regression found through traces; an RCA of the SLO breach.
Assignment: A dashboard, an SLO, two alerts and a blameless postmortem.
Checkpoint: A load test, a Helm chart, a rollback runbook, an SLO and a postmortem.
04 · Weeks 13–16
Cloud architecture, AI and capstone
Phase goal: Justify cloud and security decisions, use AI tools critically and defend the system.
Week 13
AWS and cloud architecture (Well-Architected)
- VPC, IAM and networking fundamentals
- EKS, RDS and managed messaging: when to use which
- High availability, disaster recovery and secrets
- Cost governance and a Well-Architected review
Lab: A target AWS architecture for the system, IAM policies and a monthly cost estimate (without creating paid resources).
Assignment: A Well-Architected pillar review and a DR plan (RPO/RTO).
Week 14
System design: method and security architecture
- Requirements, capacity estimation and scaling
- Design decisions with partitioning and caching
- Threat modeling, service identity and OAuth2/OIDC
- Design reviews: defending trade-offs
Lab: A live system design review with the mentor: the capstone's design document.
Assignment: A design document: requirements, capacity, C4, threat model and ADRs.
Week 15
AI-assisted engineering: Claude Code, review and risks
- Agentic workflows, project instructions and MCP concepts
- AI-generated tests and code review — validating the output
- Prompt injection, data leaks and human approval boundaries
- Cost, token discipline and reproducible evaluation
Lab: Build a feature and its tests with Claude Code; find and prove at least two defects in the AI-written code.
Assignment: An AI usage policy: which tasks, which checks, which data is never sent.
Week 16
Final architecture capstone and technical defense
- Working services, async messaging and a consistency strategy
- Deployment manifests, monitoring and automated tests
- Load tests, failure simulations and a security review
- A cost estimate, ADRs and the defense
Lab: A live demo and the system's behaviour under a failure scenario set by the mentor.
Assignment: A final technical defense assessed with a rubric (both implementation and architectural reasoning).
Checkpoint: A design document, a cost estimate, an AI usage policy and a final defense assessed with a rubric.