Distributed Monolith Anti-Pattern

## What the term names A **distributed monolith** is a system decomposed into multiple physically separate deployables — separate processes, separate repositories, separate deploy pipelines — that communicate over a network, yet still cannot be changed, tested, or deployed independently because of coupling left over from (or introduced during) the split. The physical topology says 'microservices'; the runtime behavior says 'monolith.' Common causes include: - a **database shared** by several services - long chains of **synchronous blocking calls** between services - a **shared versioned client library** that embeds business logic and forces every consumer to upgrade together - **cross-service transactions** that must commit or roll back as a unit ## Why teams end up here This pattern exists because decomposing a system is hard, and it's much easier to physically move code into a new process than to properly separate the data and behavioral ownership behind it. Teams under delivery pressure often extract a module into its own service — new repo, new deploy pipeline, new Docker image — while leaving it pointed at the same shared database and the same synchronous call patterns it used as an in-process module. The org gets to say 'we did microservices' while the actual **coupling graph**, which is what determines whether teams can move independently, hasn't changed at all. ## The trade-off The trade-off is stark and almost entirely negative. - **True microservices** trade some complexity (network calls, eventual consistency, more infrastructure) for independent deployability, independent scaling, fault isolation, and the ability for different teams to choose different release cadences or even different tech stacks. - **A distributed monolith** pays the complexity cost — network latency on every call, partial failure modes, harder distributed debugging, more moving infrastructure parts — while keeping the monolith's core liability: you still can't change one part without coordinating everyone touching the coupled parts. It is, in a very real sense, worse than either pure architecture, because it maximizes cost while minimizing benefit. ## What it looks like in production In production this shows up as: - coordinated **release trains** ('every other Tuesday, Team A, B, and C deploy together in this order') - **change-freeze windows** spanning multiple 'independent' services - incidents where a bug in one service requires a synchronized multi-service rollback, because rolling back just one breaks the API/schema contract with the others - **testing environments** that require the whole cluster running, because no service can be meaningfully exercised alone Postmortems for such systems repeatedly contain language like 'root cause in Service X caused cascading errors in Service Y,' even though Y's team made no change that day. ## The documented example A well-known, publicly documented real-world example is Segment's 2018-2020 experience: after aggressively decomposing a monolith into many small services, the engineering team found that a large share of their operational pain came from exactly this pattern — services that looked independent on an architecture diagram but were, in practice, tightly coupled through shared infrastructure, cross-service calls, and shared ownership friction, forcing coordinated changes and complicating on-call. Segment published a well-known account of consolidating some of those services back toward a more monolithic structure specifically to eliminate this **coordination tax**. The lesson generalizes: decomposition without addressing the underlying data and call-graph coupling doesn't buy autonomy, it just relocates the coupling onto a network, and the fix is not 'un-splitting' as a rule but genuinely resolving the data ownership and call-chain issues driving the coupling, of which the Segment consolidation was one team's chosen remedy for their specific context.