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.