The decision that matters
Identify which capabilities change independently, require different scaling or belong to separate teams. Keep interfaces explicit even inside a single application. A modular monolith can preserve clear boundaries while simplifying deployment and transactions. Move a capability into a separate service when the benefits justify network failures, distributed tracing, version compatibility and additional operating responsibility.
A practical scenario
A young customer portal may contain identity, documents and invoicing in one deployment while keeping their modules separate. A high-volume document processing worker could later become an independent service because its workload and failure behavior differ. Splitting every database table into a service at the beginning would create more integration work without necessarily improving the customer journey.
Before you ship
- Name the owner and reason for each proposed boundary.
- Account for failures between services.
- Keep data ownership and interface contracts explicit.
A useful next step
Draw the dependencies and deployment responsibilities of the proposed architecture. If no one can explain why a boundary exists, reconsider it. Prefer a structure the team can operate today while leaving clear seams for future change.
Primary reference & further reading
This guide combines general engineering recommendations with an illustrative scenario. Provider behavior can change; check current documentation before applying it. Read our editorial approach.