A company has split its system into 40 separately deployed services, each with its own repository and CI pipeline. Releases, however, still require a scheduled 'release train' where most services deploy together in a fixed order, and a shared database is queried directly by a dozen of the services. What architectural anti-pattern does this describe, and what does it cost the organization compared to either a true microservices style or a well-modularized monolith?

## What the scenario describes The scenario described -- many separately deployed services that nonetheless require a synchronized 'release train' and that share a database queried directly by multiple services -- is the textbook definition of a **distributed monolith**: a system that has paid the technical cost of distributing into many processes without earning the organizational benefit that distribution was supposed to buy. It looks like microservices from the repo list, but behaves like a monolith from the perspective of the thing that actually matters: can any one team ship a change on their own schedule without coordinating with others? In this scenario the answer is no, for two independent reasons that reinforce each other. ## Reason one -- the shared database The first reason is the shared database. When multiple services read and write the same tables directly, that schema becomes a **de facto shared interface**, exactly like a monolith's internal data layer, except now enforced across process and network boundaries instead of within one codebase. Any team that wants to add a column, change a type, or restructure a relation has to check whether any of the other services querying that table depend on the old shape, and coordinate the change with all of them -- the same coordination cost a monolith's shared database imposes, just spread across more org chart boxes and harder to trace because the dependency isn't visible in a single codebase's imports, it's hidden in each service's queries against tables it doesn't own. ## Reason two -- the release train The second reason is the release train itself: a fixed, scheduled, ordered deployment of most services together. This typically emerges because services have accumulated undocumented runtime assumptions about each other's current version -- one service assumes a field another just added, or two services share a library version that has to move in lockstep -- and the organization has responded by formalizing the coordination into a recurring calendar event rather than removing the coupling that made coordination necessary. Once a release train exists, it tends to become **self-reinforcing**: 1. because releases only happen on the train's schedule, teams batch up more changes per release; 2. which makes each release riskier and the coordination meeting even more important; 3. which further discourages any team from trying to break out and deploy independently. ## What it costs against the honest alternatives What this costs, compared to the two honest alternatives, is **the worst of both worlds**. - **Against a true microservices architecture** -- where each service's data is genuinely private and every inter-service call goes through a versioned, backward-compatible contract -- this system gets zero of the benefit: no team can actually ship independently, so the entire premise for taking on distributed-systems complexity never materializes. - **Against a well-modularized monolith** -- one binary, one deploy, with clean internal module boundaries enforced by the compiler rather than by network calls -- this system is strictly worse on every axis that matters here. The monolith would give the same 'we release together on a schedule' constraint this system already has, but without paying for 40 sets of infrastructure to run and monitor, without the added latency and partial-failure modes of network calls, and without the debugging tax of chasing a single logical operation's failure across a dozen services' logs instead of one call stack. The distributed monolith pays microservices' costs and collects a monolith's benefits -- none of which is a good trade. ## The fix -- pick one path honestly The fix has two forms and an organization has to pick one honestly rather than staying stuck in between. 1. **One path is to genuinely decouple.** Give each service private ownership of its own data store so no other service queries it directly, replace direct table access with calls through a versioned API kept backward-compatible so services can each deploy on their own schedule, and remove the release-train dependency incrementally as each pairwise coupling gets untangled -- this is real, often multi-quarter migration work, not a config change. 2. **The other path is to accept**, honestly, that the system's actual granularity is one deployable unit organizationally, and consolidate back toward fewer services, which at least stops paying for distribution's overhead while keeping the coordination cost the org has already accepted. ## Why it is treated as a cautionary case This pattern is widely reported in postmortems and conference talks from companies that adopted microservices as an org-wide mandate without first doing the data-ownership and contract work -- teams end up describing their systems, ruefully, as 'microservices in name, monolith in practice,' a phrase common enough in the industry's retrospective writing on early, overzealous microservices adoptions that it's treated as a standard cautionary case study.