The distributed monolith

Why can a system split into services still have to be deployed all at once?

A team spends a year splitting one application into twenty services. Separate repositories, separate containers, separate pipelines. Every structural marker of a microservice architecture is present and can be pointed at in a diagram.

Then a release goes out, and it goes out as twenty simultaneous deployments in a fixed order, gated by a meeting. Roll one back and you must roll back the others. The team is doing more work to ship than they were doing before the split — because now the release is distributed too. Nothing on the diagram is wrong. So what did the diagram fail to show?

Begin by asking what independence actually consists of, because the diagram shows only separation. Separation is a property of the artifacts: distinct processes, distinct pipelines. Independence is a property of change: can this thing be modified and released while everything else stays as it is? Those come apart easily, and nothing about drawing a box around a process makes the second one true.

So look for the mechanism that couples releases. It is always the same shape: a change to A requires a simultaneous change to B, so neither can go alone. Ask which arrangements produce that, and a short list emerges.

The most common is a shared database schema. Two services reading the same table have merged their models regardless of the diagram — an added column is safe, but a renamed or dropped one breaks the other service at the instant it lands, so the two must be released together. This is the single most reliable cause, and it usually survives a split because carving the data was harder than carving the code and got deferred.

Next, shared libraries carrying domain types. A common library holding the Order class looks like sensible reuse. But now a change to that class means every service that consumes it must be rebuilt and redeployed to keep the wire compatible — so a library that was supposed to reduce duplication has recreated the single build. Reuse of technical utilities is harmless; reuse of domain model is a shared kernel with no ceremony around it.

Third, breaking contract changes without a transition period. If a producer changes a field's meaning and expects consumers to have updated by the same second, the deployments are welded. The alternative is well known — add the new field, support both shapes, migrate consumers, remove the old one later — but it takes three releases where one feels sufficient, so it is skipped under time pressure. Notice that this is a discipline failure rather than a structural one, which is why it recurs even in well-drawn architectures.

Fourth, synchronous call chains with no tolerance for absence. If a request traverses six services and every one must be up and at the matching version, effective availability is the product of theirs, and each deploy is a brief outage downstream. Independence in the source is worthless if the runtime cannot survive one participant restarting.

Fifth, and least discussed, distributed transactional expectations. If a workflow assumes several services commit or fail together, they are coupled in a way no contract versioning can dissolve, because the coupling is semantic.

Now stand back and notice what all five have in common. Each is a place where two services must agree on something at the moment of deployment. That gives a definition sharper than any structural one: a distributed monolith is a system whose components must agree at release time, whatever their runtime topology looks like. The word "monolith" is exact — the unit of release is still the whole thing.

Which explains the bitter arithmetic. Against a real monolith you have swapped in-process calls for network calls, one transaction for none, one log for twenty, and one deploy for a choreographed twenty — every cost of distribution paid, and the coordination cost the split was supposed to remove still kept. It is the worst of the two designs, and not rare: it is the default outcome when boundaries are drawn by technical layer rather than by capability, because a layered cut guarantees every feature crosses every boundary.

Is there a test that does not depend on judgement? Yes, and it is blunt: pick one service, change something in it, and try to release it alone this afternoon. Whether you can is the answer — every other measure, repository count or lines per service, is a proxy this question makes unnecessary. The diagnostic version is to look at deployment history and ask how often two services shipped within the same hour; a strong correlation is coupling made visible in data.

The misconception worth naming is that this is a problem of granularity — that the services were too big, or too small, and resizing will fix it. Size is not the variable. A system of three services, each independently releasable, is not a distributed monolith; a system of three hundred that ship together is. Splitting further while the shared schema remains simply multiplies the participants in the same coordinated release.

Two refinements. First, some deployment coupling is legitimate and temporary. A planned two-step migration where a producer and consumer move within the same window is fine as an episode; it becomes the pathology when it is the steady state — when every release, not an occasional one, is choreographed.

Second, the remedy is unglamorous and sequential: separate the data first, because shared schema is the coupling no amount of contract discipline works around; then make contracts additive; then add contract tests so a breaking change fails in the producer's own pipeline. Merging services back together is also legitimate and under-used — two services that always ship together are one service made expensive to operate.

• How consumer-driven contract testing moves breakage detection into the producer's own pipeline, and what it still cannot catch.
• The expand-and-contract migration for splitting a shared schema without a coordinated release.

Every term the collection defines is gathered in the glossary.