Chapter 18 — Microservices Architecture

Core ideas

• Domain-partitioned, distributed, single-purpose, fine-grained services that are independently deployable and own their own data (each service = its own architecture quantum, bounded context from DDD). Share nothing; duplicate rather than couple.
• Granularity is the hardest question: disintegrators (reasons to split — functionality, code volatility, scalability, fault tolerance, security, extensibility) vs. integrators (reasons to keep together — database transactions, workflow/choreography coupling, shared code). Avoid too-fine (“nanoservices”/grain trap) and too-coarse.
• Data isolation is mandatory (no shared DB). Inter-service communication: choreography (broker-style, decentralized) vs. orchestration (a service orchestrator); transactional sagas and compensating transactions for cross-service consistency.
• Operational backbone: API layer/gateway, service discovery, sidecars & the service mesh (operational coupling/observability extracted into a consistent plane), automated deployment, monitoring/observability. Handling errors, timeouts, and the network fallacies is a first-class concern.

Trade-offs / when to use

Top marks for evolvability, deployability, testability (per service), scalability, elasticity, fault tolerance. Worst marks for cost and simplicity; performance can suffer from network hops (mitigate by not making services too fine and by choosing communication carefully). Choose when independent evolution/deploy/scale of many domains genuinely justifies the operational tax — not by default.

Terms to own

bounded context, data isolation, granularity disintegrators/integrators, saga & compensating transaction, choreography vs. orchestration, sidecar/service mesh, service discovery, API gateway.