Most microservice problems are born long before RPC. They usually begin when the system is cut along the wrong seams.
In real design work, the chapter shows how bounded contexts, business capabilities, team topology, and data ownership shape decomposition far more than repository layout or implementation language.
In interviews and engineering discussions, it helps stress-test decomposition against distributed-monolith risk, expensive cross-service transactions, and orchestration-heavy coupling between teams.
Practical value of this chapter
Design in practice
Split systems by business capabilities, not by technical layers or repository boundaries.
Decision quality
Evaluate cuts using data ownership, team topology, and cross-service transaction frequency.
Interview articulation
Explain how the chosen cut reduces coupling and enables independent releases.
Failure framing
Stress-test decomposition against distributed-monolith risk and orchestration over-coupling.
Context
Microservices and Integration
Decomposition is a fundamental step that determines subsequent communications and operational complexity.
Decomposition Strategies determine where service boundaries are, who owns the data, and how quickly teams can deliver changes. A mistake at this step usually results in an expensive architecture redesign 1-2 years later.
Decomposition Drivers
- Independent delivery of changes by different teams without blocking each other.
- Separation of areas of responsibility (domain ownership) and reduction of cognitive load.
- Availability of different load profiles and scaling requirements across subsystems.
- We need isolation of failures and the ability to degrade individual capabilities, not the entire product.
Axes of decomposition
Business capability
Division by business capabilities: billing, catalog, fulfillment, identity. Usually the best starting point.
Bounded context (DDD)
The service boundary coincides with the domain model and ubiquitous language. Reduces conflicting interpretations of data.
Team topology
Services are designed so that ownership and runtime responsibility are shared by one team.
Data ownership
Each service owns its own storage and schema; cross-service join is replaced by API/events.
Migration
Monolith to Microservices
Sam Newman's book gives practical steps and risks of migrating from a monolith to services.
Migration Strategies
Strangler Fig: gradually move streams out of the monolith behind the API-gateway/route layer.
Branch by Abstraction: first the abstraction is introduced, then the implementation underneath it is gradually changed.
Extract by volatility: extract the most volatile and independent parts of the domain first.
Migration by seams: highlight technical and domain seams (authentication, notifications, reporting).
Typical antipatterns
Nano-services: too small services with high connectivity and complex coordination.
Shared database as the main contract between services.
Decomposition into technical layers instead of business boundaries (service A = API, service B = DB).
Premature decomposition without observability, CI/CD and ownership model.
Practical checklist
- Each service has a clear owner and an SLA/SLO contract with its neighbors.
- Service boundaries reflect domain boundaries, not the structure of the code in the monolith.
- Cross-service dependencies are documented and have fallback/degradation behavior.
- For each extraction step there is a rollback strategy and migration success metrics.
- Data and write-path ownership are not spread across multiple services.
References
Related chapters
- Monolith to Microservices - Practical strategies for extracting services from a monolithic system.
- Learning Domain-Driven Design - DDD approach to domain boundaries and bounded context decomposition.
- Interservice communication patterns - After decomposition, you need to select stable patterns of interaction between services.
- Service Discovery - The growth in the number of services requires controlled discovery and routing of traffic.
- Microservices and Integration: An Overview - Introductory context and place of decomposition in the overall architectural picture.