When Not to Distribute

This asymmetry is the entire argument and it deserves to be stated without hedging. On the day you split a component out, you receive: partial failure between the halves, ambiguous outcomes on every call between them, an unbounded latency tail, a new deployment unit, a new failure domain, a new set of dashboards, and a debugging story that now spans two processes. You receive all of that whether or not the split ever pays off.

What you receive *conditionally* is capacity if the work partitions, availability if the failures are independent, locality if the data can be local, isolation if there is no shared dependency. Each condition is an assumption about the future, and the industry’s record on those assumptions is not good. The most common outcome of a premature split is a system with all of the costs and a fraction of the benefit — a The Distributed Monolith: All of the Cost, None of the Autonomy, which is genuinely worse than either alternative.

The honest framing is therefore not "monolith versus microservices". It is: you are buying an option, the premium is non-refundable, and you should know what you are buying it for.

The intuition most engineers carry about single-machine limits is a decade out of date. A commodity server today has dozens of cores, hundreds of gigabytes of RAM, and NVMe storage that delivers hundreds of thousands of IOPS. A well-written service on such a machine handles tens of thousands of requests per second; a relational database on one handles workloads that most companies will never reach.

Meanwhile the constant factors of distribution work against you. A local function call is nanoseconds; a call to a service in the same zone is a few hundred microseconds at best — three to four orders of magnitude. Splitting a request path into six services turns one in-process traversal into five network hops with five latency tails and five failure domains. It is entirely normal for a decomposed system to be *slower* than the monolith it replaced, at higher cost, and for that to be discovered after the migration.

This is not an argument that single machines are always enough. It is an argument that the number where they stop being enough is much higher than the number at which teams typically split, and that the difference is usually the algorithm, the index or the N+1 rather than the machine.

The strongest real-world case for splitting is rarely technical. It is that two groups of people want to release independently, own their operational fate, and stop coordinating on a shared deploy. That is a legitimate benefit and it is worth money. It also has a precondition that is easy to skip: the boundary must match how the system changes. If a typical feature touches three of your services, you have not decoupled the teams; you have added a release-coordination protocol implemented in humans.

It is also worth noticing that most of the deployment-independence benefit is available without the network. A modular monolith with enforced internal boundaries — separate modules, no reaching into another module’s data, an explicit interface — gives you the design discipline, the ability to reason about ownership, and a straightforward path to extraction later, at the point where you have evidence about which boundary is real. Architecture treats the pattern; the distributed-systems point is that you can adopt the boundary without adopting partial failure, and the boundary is where most of the value is.

The reverse is not true. Once the network is in the middle, taking it out again is a migration. Boundaries are cheap to add and expensive to remove, which argues for adding them late and in the place the evidence points to.

A few situations are clear enough to state as guidance rather than as trade-off. When the components must never disagree: two things that share an invariant are cheaper as one unit than as two with a consensus protocol between them, and every attempt to enforce a cross-service invariant reinvents distributed transactions badly. When the team is smaller than the number of services: you are guaranteeing that each service has less than one owner. When the requirement is unknown: you are choosing a partition of a problem you have not yet understood.

And a subtler one: when the split would make failure correlated rather than independent. Splitting a component out onto separate machines that share a database, a cache, or an identity service does not give you two failure domains. It gives you one failure domain with an extra network hop in it — the worst possible trade, since you pay the distribution cost and keep the shared fate. Fault Domains: What Fails Together and Correlated Failure: The Independence Assumption Is Usually False are where this is worked through, and it is worth checking before the split rather than during the incident.