Composite example. This combines recurring patterns from similar cases. Names are omitted; it is not a report about one identifiable organisation.
Starting point
A growing commerce monolith still works, but deployments are tense. A team splits it into many services, expecting independent scaling and delivery.
What the team built
- Services were split along technical entities and layers.
- One request crossed several synchronous service calls in a chain.
- All services shared one database.
- Changes across several services required coordinated deployments.
Why the design struggled
Network hops added latency and new failure modes. One slow service held up the entire chain. A shared schema created hidden coupling; changing it could break another service. Coordinated deployments removed much of the intended autonomy while keeping the operational burden of distribution.
Questions to ask early
- Can these services change and deploy independently?
- What happens to the user journey when one dependency fails?
- Why is the database shared and who owns each piece of data?
- Were boundaries chosen by business capability and ownership, or by technical layer?
Better decision
Start with clear modules and ownership. Extract a service when independent scaling, ownership or deployment has a demonstrated value. Keep write ownership behind a clear boundary. Use asynchronous communication when the business process allows it and failure isolation requires it; account for eventual consistency and operations.
Distribution is useful when it creates independence. A network boundary alone does not.