The Simple Version
When a system has too many moving parts that need to stay in sync, adding more parts often makes failures more likely, not less. Sometimes the most reliable architecture is a smaller one.
The Counterintuitive Math of Reliability
Reliability in distributed systems is multiplicative, not additive. If you have three servers that each run with 99% uptime, the chance that all three are simultaneously available isn’t 99%. It’s roughly 97%. Add a fourth server into a chain where all of them must cooperate, and you’re down to 96%. Each component you add is another place the whole thing can fail.
This is why the instinct to “add redundancy” can quietly make systems worse. Engineers reach for extra servers the way a nervous cook reaches for more salt. Sometimes the dish doesn’t need salt. Sometimes it needs fewer ingredients.
The scenario where deleting a server genuinely triples reliability isn’t a paradox once you understand what was happening before the deletion. You had a bottleneck node: a server that every request had to touch, that held state no other server could replicate, and that sat at the center of a web of dependencies. Its availability was the ceiling on the whole system’s availability. Everything else was just waiting for it to fail.
The Problem With Stateful Middlemen
The specific failure mode here has a name in distributed systems design: the single point of failure. But the subtler version, the one that actually kills production systems, isn’t the obvious single point. It’s the node that was designed to be stateful because that seemed like the tidy engineering choice at the time.
Consider a coordination service sitting between your application servers and your database. Its job is to track which application server is handling which session. That sounds reasonable. Sessions need to live somewhere. But now you have a system where that coordination service must be up for any request to complete. Its 99.5% uptime sounds impressive until you multiply it against your application server uptime and your database uptime and realize your end-to-end availability is noticeably worse than any individual component.
The fix isn’t always to make the coordination service more reliable. Often the fix is to ask whether the coordination service needs to exist. If sessions can be stateless (stored in a signed token the client carries, for instance), you’ve eliminated the dependency entirely. The server disappears. The system gets faster, simpler, and more reliable in a single move.
This is the logic behind JWT authentication tokens, behind stateless REST APIs, behind a significant chunk of modern backend architecture. The question isn’t “how do we make this service more reliable?” It’s “can we eliminate the need for this service?”
Why Engineers Don’t Do This By Default
Deleting infrastructure feels reckless. It runs against the grain of how most engineers are trained to think about risk. The risk of adding something is invisible and gradual. The risk of removing something is vivid and immediate. If you add a redundant server and the system fails next week, nobody connects those two events. If you delete a server and the system fails next week, the causal story writes itself.
This asymmetry in perceived blame keeps a lot of unnecessary infrastructure running. There’s also an organizational dimension: the team that built the coordination service has professional identity wrapped up in it. Deleting their server is not a neutral technical act.
The engineers who actually do this well tend to share a particular habit: they measure the failure contribution of each component, not just its individual uptime. A component with 99.9% uptime that sits in a critical path is more dangerous than a component with 99% uptime that only affects a non-critical feature. The number that matters is how much each piece degrades the whole.
What “Simpler” Actually Means in Engineering
Simplicity in software engineering is frequently misunderstood as a preference, a personality trait some engineers have and others don’t. It isn’t. It’s a compounding reliability investment. Every service you remove is a service that can’t page you at 3am, can’t have a certificate expire, can’t have a version conflict with a dependency, can’t become a single point of failure when its primary engineer leaves the company.
This is related to a broader tension in distributed systems that the microservice architecture movement surfaced sharply. Breaking a monolith into small services gives you independent deployability, but it introduces coordination overhead, network latency between services, and more components whose uptime now constrains the whole. The companies that handled this well treated service decomposition as a tool for specific problems, not a default architecture.
The teams that delete servers and see reliability improve aren’t doing something clever or counterintuitive. They’re doing something disciplined. They mapped their dependencies, found a node whose removal could be absorbed by redesigning how state was handled, and made the harder architectural choice instead of the easier operational one.
The Principle Worth Keeping
Before adding a server, ask whether you’re solving a problem or distributing one. Before adding a service, ask whether the coordination cost of that service exceeds the cost of the problem it solves. When reliability degrades and the instinct is to add monitoring, add redundancy, add a failover cluster, pause first and ask whether the right answer is subtraction.
The systems that age well tend to be the ones whose architects were willing to feel the short-term discomfort of simplification. The ones that don’t age well are archaeological sites: layer after layer of solutions to problems that no longer exist, each layer adding to the blast radius when something finally breaks.
Deleting a server is sometimes the bravest engineering decision a team can make. The three-times reliability improvement isn’t magic. It’s just what’s left when you stop insisting that complexity is the same thing as capability.
