A team runs a critical service on a single server. The server has 99.95% uptime — about four hours of downtime per year. Leadership decides four hours is too much. Someone proposes "add redundancy." Six months later, the team has three servers, an active-passive failover, a runbook nobody has read since the migration, and a service that is going down more often than before because the failover is flaky and the team has not practised it.
This is the most common redundancy mistake: treating redundancy as a single concept rather than as a recurring pattern that shows up at every layer of the stack with different mechanics, different costs, and different failure modes.
Redundancy is one of the twelve recurring threads (T6) in The Computing Series. Its root form is simple. Its application is not.
The Root Form
Keep multiple copies of the same data or capability. If one copy fails, another serves the request. Redundancy converts single points of failure into tolerated failures.
That is the whole idea. The complexity comes from where you place the copies, how many you keep, and how you resolve conflicts when copies disagree.
The question is never whether to have redundancy. Hardware fails. Networks partition. Processes crash. Any system that must remain available while individual components fail must have redundancy. The question is where to place it and how many copies to keep.
The Thread Across the Stack
Redundancy looks different at every layer. The mathematics is the same.
Proof by cases (algorithms). A proof by cases asserts a property by checking all possibilities. The redundancy is in the proof structure: each case is independently verified, and the conclusion holds if any single case fails the team's review. The "copies" are the cases themselves.
RAID at the disk layer. RAID-1 mirrors every byte to two disks. A disk failure does not lose data. RAID-5 keeps parity blocks across N disks; any one disk can fail without data loss. Same idea: multiple copies of the same information, with a recovery procedure when one copy is lost.
Database replication. Leader-follower replication keeps copies of the database on multiple nodes. A leader handles writes; followers replicate. If the leader fails, a follower is promoted. Same idea, scaled to a system: multiple copies, with a defined recovery procedure.
Stateless service replicas. Multiple instances of a stateless service behind a load balancer. Any instance can handle any request. If one instance fails, the load balancer routes around it. Same idea, scaled further: capabilities replicated instead of data.
Multi-region deployment. Copies of the entire system in multiple geographic regions. A region failure does not take down the service. Same idea, scaled to the geographic limit.
Redundant network paths. BGP routing maintains multiple paths to every destination. A link failure is detected by neighbours, and traffic shifts to the alternative path. Same idea, applied to connectivity.
Organisational redundancy. No single engineer is the only person who can debug a critical service. Documentation, code review, on-call rotation — these are all redundancy mechanisms at the team level. The capability of "knowing how this service works" is replicated across multiple humans.
The pattern repeats. The mathematics is identical. The scale and the consequences are different.
What Redundancy Does Not Do
Redundancy does not eliminate failure. It changes the failure mode.
With one database server, failure is data unavailability — the service stops working. With three database servers, failure becomes a consistency question — which copy is authoritative? When the leader fails and a follower is promoted, has all the leader's most recent data been replicated? If not, was it durably written? Is the system now eventually consistent, or has it lost writes that the client believed succeeded?
The thread T9 (Consensus) exists entirely to answer this question. Raft, Paxos, and quorum reads are the algorithms that let distributed replicas agree on which version of the state is current. Without them, redundancy produces multiple copies that disagree (FM4) or both believe they are authoritative (FM12 — split-brain).
The same shift happens at the organisational layer. With one engineer who knows the system, the failure mode is that engineer being unavailable. With three engineers who know it, the failure mode is that the three engineers have slightly different mental models, and the engineer on call may apply the wrong one to an incident.
Redundancy is not a free win. It converts one set of failure modes into a different set.
Setting the Level Correctly
The right level of redundancy is determined by the availability requirement in the SLO. Not by intuition. Not by "more is safer."
For a 99.9% SLO (8.76 hours of allowed downtime per year), single-region replicas behind a load balancer are usually enough. For 99.95%, you need automated failover that actually works. For 99.99% (52 minutes per year), you need multi-region. For 99.999% (5 minutes per year), you are designing the entire stack around redundancy from the ground up, and you need to be prepared to spend.
Each additional nine costs roughly an order of magnitude more in operational complexity. The decision is not "do we want more nines?" — every team wants more nines. The decision is "are we willing to pay the cost of operating at that level of redundancy?" Most teams overstate the SLO they actually need.
N+1 is the minimum for any component on the critical path. If you have one of something, you have a SPOF. Two is the smallest configuration that survives a failure. Three is the smallest that survives a failure during maintenance. Anything beyond depends on the SLO.
Where Redundancy Fails
FM12 (Split-Brain). Two replicas each believe they are the primary and accept conflicting writes. This is the failure mode that consensus algorithms exist to prevent — and the failure mode that occurs when the consensus algorithm is configured wrong (quorum sizes that don't add up, network partitions that produce two partitions each containing a majority of their visible nodes).
FM4 (Data Consistency Failure). Replicas disagree about state. The cache says the inventory is 5; the database says 0. A user buys the item. The application reads from the cache and the order succeeds. The database reads true zero and the order cannot be fulfilled. The failure was not the absence of redundancy — it was redundancy without a consistency model.
FM11 (Observability Blindness). Operators cannot tell whether a failover succeeded, whether replicas are in sync, or whether the system is currently running with reduced redundancy. The system appears healthy on every dashboard while operating in a degraded state. The next failure — which the redundancy was supposed to absorb — produces an outage.
Organisational redundancy failure. The on-call rotation has five engineers. Four have not been on call in six months. When the actual incident comes, the engineer on call has a stale mental model and the four off-call engineers are not reachable. The redundancy was theoretical, not practiced.
The Question to Ask Before Adding Redundancy
When someone proposes adding redundancy to a component, the right questions are not "should we?" They are:
- What is the failure mode this redundancy is supposed to absorb? (If you cannot name the failure mode, you do not know what you are buying.)
- What is the consistency model when the copies disagree? (If the answer is "they should never disagree," see FM12.)
- What is the failover procedure, and when did we last practise it? (Untested redundancy is theatre.)
- What new failure modes does this redundancy introduce? (Consensus failures, replication lag, split-brain — these are new failure surfaces.)
- Does the SLO actually require this level of redundancy? (Most teams over-engineer this.)
Redundancy is not a feature. It is a tradeoff. The cost is operational complexity, additional failure modes, and the ongoing discipline to keep redundant systems actually redundant.
The T6 thread is named in The Engineer's Map — Chapter 3: The Twelve Threads (Book 0). This article extracts it where it has the most operational consequences: Book 3, Chapter 8 — Database Replication. The book3 chapter walks through all three replication architectures (leader-follower, multi-leader, leaderless), the LSN-based replication protocol, the read-your-own-write fix, multi-leader conflict resolution patterns, and the design problem for a global financial ledger.