A company has split its monolith into 15 separately-deployed services, but every release still requires deploying most of them together in a fixed order, and a single slow service brings down request chains everywhere. What is this failure mode called, and what specific decomposition mistakes typically cause it?

## What a distributed monolith is A **distributed monolith** is a system that has been physically split into multiple independently-deployed services but has not shed the coupling that made it a monolith in the first place — the result is that you pay every operational cost of distribution (network latency, serialization, more infrastructure to run and monitor, more places for partial failure) while getting none of microservices' actual payoff, which is independent development, testing, and deployment per service. It typically forms through a handful of specific, identifiable mistakes made during decomposition rather than as some unavoidable fate of splitting a system. ## The four decomposition mistakes behind it 1. **The first and most common cause is drawing boundaries along technical layers instead of business capabilities** — separate services for presentation, business rules, and data access — so that any real business change fans out across most of the services and has to be deployed together. 2. **The second is a shared database or shared schema**: if two services read or write the same tables, or even just share a library that defines the canonical shape of a core entity, then a schema change in one forces a coordinated migration and deploy in the other, and neither can evolve its data model independently even though they run in separate processes. 3. **The third is deep synchronous call chains**: when handling one request requires service A to call B, which calls C, which calls D, the whole chain's availability is the product of every link's availability, and the whole chain's latency is at least the sum of every link's latency — a slowdown or outage anywhere propagates upward to every caller, with no isolation the way there would be with async, event-driven integration. 4. **The fourth is shared business-logic libraries**, as opposed to genuinely generic utility code, baked into every service: if a validation rule or pricing calculation lives in a shared package that every service links against, changing that rule still requires rebuilding and redeploying every consumer in lockstep, exactly as it would in a monolith's shared internal module. ## Why it is so expensive to fix The trade-off in fixing this is significant, which is part of why organizations stay stuck in it: - **Untangling a shared database** means picking apart which service really owns which tables and migrating data ownership, a multi-step, carefully sequenced project, not a config change. - **Replacing synchronous call chains with asynchronous events** means accepting eventual consistency somewhere you previously had a synchronous guarantee, and reworking client code to no longer expect an immediate, always-fresh answer. - **Splitting a shared code library into per-service copies**, accepting some duplication, trades an easy central update point for genuine independence. None of these fixes are free, which is why distributed monoliths, once formed, tend to persist for a long time — the remediation looks a lot like doing the original decomposition work properly, except now on a live system with sunk cost in the existing shape. ## Failure modes The failure modes show up operationally rather than in a design document: - release runbooks that specify a fixed order across several 'independent' services because contract changes silently break downstream consumers; - a single slow or degraded service, or its external dependency, causing timeouts and error-rate spikes across several unrelated-looking services because they're all synchronously chained together; - integration tests that require spinning up the full set of services to pass because none of them can be meaningfully verified in isolation; - and on-call engineers who can't confidently say what breaks if they deploy just one service, so they default to deploying several together 'to be safe,' which further entrenches the coupling. ## Where it shows up This term and the underlying anti-pattern are extensively discussed by **Sam Newman** in his writing on microservices, as one of the primary risks of decomposing a system's deployment topology without also decomposing its actual coupling — data ownership, call topology, and contract stability. A common concrete instance is a checkout flow where Cart, Pricing, Tax, and Payment services all call each other synchronously and share a customers table maintained by none of them cleanly; a slow third-party tax-rate lookup inside the Tax service then degrades checkout latency across the board, and nobody can deploy a Pricing change without first checking whether it breaks Tax's assumptions about the shape of a price object — **the system is fifteen containers wide and one monolith deep**.