VI. Microservice Architecture Patterns
Microservices are an organizational solution disguised as a technical one: they let independent teams deploy independently, at the cost of turning every in-process call into a network call with its own failure mode. Adopt them for the wrong reasons and you get a distributed monolith — all the complexity of the network with none of the independence. This part covers how to draw service boundaries that hold, the structural and discovery patterns that connect them, and the data patterns (per-service databases, event sourcing, CQRS) that keep them decoupled.
Topics Covered
Section titled “Topics Covered”- 6.1. Service Decomposition Strategies: Drawing service boundaries that hold: Domain-Driven Design, Conway’s Law, the distributed-monolith anti-pattern, and the modular monolith.
- 6.2. Structural Patterns: Deploying cross-cutting behavior as separate processes: sidecar, ambassador, adapter, and anti-corruption layer patterns.
- 6.3. Service Discovery: Finding dependencies in a dynamic environment: client-side and server-side discovery, registration, and health-check patterns.
- 6.4. Data Management Patterns: Managing data without shared databases: database-per-service, API composition, polyglot persistence, and materialized views.
- 6.5. Event Sourcing and CQRS: Storing change instead of state: event sourcing, event store design, CQRS, projections, versioning, and snapshots.