Level 9: Microservices
Decide whether microservices are worth it, draw service boundaries, and design communication and failure handling that survive production.
Outcome: Decide whether microservices are worth it, draw service boundaries, and design communication and failure handling that survive production.
Teams want to deploy independently. We split ShopFlow carefully — boundaries from DDD, data ownership, sync vs async communication, sagas, resilience, observability, deployment and team ownership.
The pressure on ShopFlow: Four teams block each other on every release; Black Friday traffic hits only checkout.
Lessons in level 9
- Why Microservices Exist — and When Not to Use Them — Independent deployability is the point; complexity is the price.
- Finding Service Boundaries & Splitting the Monolith — Information hiding, bounded contexts and the strangler fig.
- Database per Service & Data Ownership — Why sharing a database couples services, and how to live without joins.
- Synchronous vs Asynchronous Communication — REST, gRPC and events — temporal coupling and its consequences.
- API Gateways, BFFs & Service Discovery — How clients find services, and what belongs at the edge.
- Timeouts, Retries & Retry Storms — Why naive retries turn a slow service into an outage.
- Circuit Breakers & Bulkheads — Fail fast, isolate damage, and recover gracefully.
- Idempotency: Making Retries Safe — Idempotency keys, deduplication and the myth of exactly-once.
- Distributed Transactions: 2PC, Sagas & the Outbox — Keep data consistent across services without a global transaction.
- Observability: Logs, Metrics, Traces & SLOs — Answer “why is checkout slow?” across ten services.
- Deployment: Containers, Kubernetes, Canary & Feature Flags — Ship small, ship often, and limit the blast radius.
- Testing Microservices & Consumer-Driven Contracts — Catch breaking API changes without a giant end-to-end suite.
- Teams, Ownership & Conway’s Law — Architecture and org charts shape each other.
Source books
- Building Microservices — Sam Newman
- DDD — Eric Evans
- Software Architecture — Mark Richards, Neal Ford, Pramod Sadalage, Zhamak Dehghani
- DDIA — Martin Kleppmann