Is a distributed monolith always a mistake to fix immediately? Discuss when it can be a rational, temporary state, and how Conway's Law and team topology influence whether it persists.

## Transitional against stuck The anti-pattern label properly applies to the stuck, permanent state, not to every instance of temporary coupling. A team executing a well-planned **strangler-fig migration** will, by design, pass through states that look exactly like a distributed monolith — a shared database mid-split, some synchronous calls not yet converted to async — and that's expected and fine as long as it's actively moving toward the target, with a plan and shrinking coupling over time. It becomes the true anti-pattern when it is the resting, steady state: no plan, no shrinking trend, coupling accepted indefinitely as simply how the system is. ## When accepting it is rational There are rational reasons to accept it temporarily or even in limited permanent scope. - **Premature decomposition is a real risk.** Splitting data and call paths before the domain model is well understood often produces the wrong boundaries, forcing an expensive redo, so a temporary shared database can be safer than guessing. - **The migration has a real cost.** Full data-ownership migration, with dual writes, event sourcing, and contract tests, is genuinely expensive engineering time that competes with feature work, so an organization may rationally sequence it behind higher-value work while explicitly tracking it as debt with an owner and a rough timeline, rather than deferring it indefinitely with no plan. - **Scale also matters.** A small team running several 'microservices' that are really a distributed monolith may be entirely rational, since the coordination cost of a shared database is low when one team already touches everything, and the organization hasn't yet grown enough independent teams to benefit from true service autonomy. ## Why Conway's Law keeps it alive **Conway's Law**, Melvin Conway's 1968 observation that organizations design systems mirroring their own communication structure, explains why this persists. - **One team owns both.** If one team, or a small, tightly synced set of teams, is responsible for both 'Service A' and 'Service B,' the coordination overhead of a cross-boundary change is near zero for that team — they simply talk to themselves. There's no organizational pain driving investment in decoupling the code, so shared-database and lockstep-deploy patterns persist indefinitely because the team absorbs the coupling cost internally without much friction. - **The team boundary crosses the service boundary.** Conversely, when the team boundary actually crosses the service boundary — two separate teams, on different roadmaps, with different priorities, owning A and B respectively — the coordination cost of the existing coupling becomes visible and painful: blocked pull requests, scheduling conflicts, and cross-team meetings to plan every shared release. That visible organizational pain is typically what forces genuine investment in autonomy. ## The implication for practice This has a direct implication for practice: the fix for a chronically stuck distributed monolith is often organizational before it's technical. If genuine independence between two services is the goal, put genuinely independent teams in charge of them — the **'Inverse Conway Maneuver,'** popularized in the Team Topologies literature, deliberately reorganizes team boundaries toward the target architecture and lets the resulting communication friction pressure the code to follow. The reverse mistake is also real: restructuring teams around service boundaries without doing the corresponding technical remediation work produces two teams fighting over one shared, still-coupled codebase, which can be worse in the short term, with constant cross-team blocking, than one team quietly tolerating self-inflicted coupling. ## A worked scenario A worked scenario illustrates the mechanism: a company splits its 'Orders' monolith module into a nominal 'Orders Service' and 'Fulfillment Service' during a reorg, assigning each to a different team, but doesn't yet split the underlying database or the synchronous call chain between them. Cross-team friction spikes immediately — schema-change pull requests blocked on cross-team review, deploy-coordination meetings — which is unpleasant short term, but is exactly the pressure that, within a couple of quarters, drives the teams to actually invest in single-writer ownership and event-driven decoupling, because the pain is now felt by the people with the authority and incentive to fix it, rather than absorbed silently by one team that never prioritized it. The principal-level insight this reveals is that technical remediation plans are necessary but not sufficient on their own: they only receive sustained investment, and don't silently regress back into coupling, when the team topology is aligned so that autonomy is the path of least resistance for the people doing the day-to-day work.