The distributed monolith

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.