What is a distributed monolith, what symptoms reveal one, and how does carelessly combining architectural styles produce it?

## Definition A **distributed monolith** is an architecture that has been physically split into multiple deployable units but remains logically one unit: the parts cannot be built, tested, deployed, scaled or failed independently. It is the worst of both worlds - the coupling of a monolith plus the network, operations and debugging burden of a distributed system. ## Diagnostic symptoms 1. **Lockstep deployment** - releasing a feature requires deploying services A, B and C in a specific order, often behind a change freeze. This is the primary test: if you cannot deploy one service on its own, you do not have services. 2. **Shared database schema** - several services read and write the same tables. Any schema change coordinates all of them, and each service's internal state is publicly writable, so invariants cannot be enforced anywhere. 3. **Deep synchronous call chains** - one user request traverses five services. Latencies add; availabilities multiply (five hops at 99.9% is roughly 99.5%); one slow hop stalls everything. 4. **A shared 'common' library that must match everywhere** - domain entities or DTOs in a library where a version bump forces a coordinated rollout is compile-time coupling wearing a distributed costume. 5. **Business transactions spanning services** - a single operation needs atomicity across services, so teams reach for distributed transactions or ad-hoc rollback code. 6. **Cannot test in isolation** - running one service's tests requires five other services or a full shared environment. 7. **Correlated failure** - when one non-critical service is down, unrelated features stop working; there is no fallback or bulkhead. 8. **Chatty cross-service traffic for one screen** - dozens of fine-grained calls indicate a boundary that cuts through a cohesive concept. ## Root causes - **Splitting by technical layer instead of business capability.** A 'controller service', 'business-logic service' and 'data service' guarantee that every feature touches all three. Slice by capability (ordering, billing, catalogue) so most changes land inside one boundary. The general principle is high cohesion inside a boundary and low coupling across it. - **Extracting services but not their data.** Code moves out, tables stay shared. Data ownership is the actual boundary; without it there is no independence. - **Adding a broker while keeping request/reply everywhere.** Publishing a message and blocking for a reply retains temporal coupling and merely adds a hop. - **Splitting on team or repository convenience** rather than on domain seams, so seams run through cohesive concepts. - **Splitting too early**, before the domain is understood, so boundaries get drawn in the wrong places and become expensive to move once distributed. - **Sharing domain models across services** through a library or a common schema, which couples every service to one team's modelling decisions. ## Why careless style-mixing produces it Each style carries prerequisites, and hybrids fail when a style is adopted for its benefits while its prerequisites are skipped. Microservices require independently owned data, versioned contracts and per-service pipelines; adopt the deployment split without the data split and you have a distributed monolith. Event-driven integration requires accepting eventual consistency and designing idempotent consumers; adopt the broker but demand immediate consistency and synchronous replies, and you added infrastructure without removing coupling. Serverless edges require integrating through published APIs; skip that and functions become extra writers to the same schema. The pattern is constant: **take the topology of a style but not its discipline.** ## Getting out - Measure the real metric: **can each service be deployed to production alone, at any time?** Track deployment coupling as a first-class number. - Fix data ownership first - split the schema, migrate to per-service data, replicate read-only copies through events where needed. - Redraw boundaries around bounded contexts by observing which changes touch which services; merge services that always change together. - Convert cross-boundary synchronous calls to events where the caller does not need an answer now; model multi-service workflows as sagas with compensation. - Version contracts and enforce them with **consumer-driven contract tests** so a provider can deploy without a big-bang integration environment. - Consider **merging back**. A well-modularised monolith is a legitimate and often better destination; recombination is a valid architectural move, not an admission of defeat.