Redundancy

Redundancy means you have more than one of something that matters, on purpose. If a single web server, disk, network link, or database can take your whole system down when it dies, that component is a single point of failure. Redundancy removes that single point by adding one or more standby or active duplicates.

The key idea is that hardware and software fail constantly at scale. A disk has a roughly 1 to 2 percent annual failure rate, so in a fleet of 10,000 disks you expect a few failures every week. A single server might offer 99.9 percent uptime, which sounds great until you realize that is almost 9 hours of downtime a year. Redundancy is how you turn unreliable parts into a reliable whole.

Redundancy is not the same as backup. A backup is a copy you restore from after something goes wrong, often hours later. Redundancy is a live duplicate that takes over in seconds or less, with no data lost. You usually want both.

There are two main flavors. Active-active means every copy serves traffic at the same time, and a load balancer spreads requests across them. If one dies, the others simply absorb its share. Active-passive means one copy serves traffic while a standby waits idle, ready to be promoted when the primary fails. Active-active gives you extra capacity for free, while active-passive is simpler and avoids conflicts on writes.

Redundancy needs three pieces to work: detection, failover, and recovery. Health checks detect that a component is down, usually by pinging it every few seconds and marking it unhealthy after a couple of missed responses. Failover routes traffic away from the dead copy to a healthy one. Recovery brings the failed copy back, or spins up a fresh one, so you are protected again.

The hard part is state. Stateless web servers are easy to duplicate because any copy can handle any request. Databases are harder because the copies must agree on the data. Systems solve this with replication, where writes flow from a primary to replicas, and with consensus protocols like Raft or Paxos that let a group of nodes elect a new leader and stay consistent when one fails.

Add redundancy to anything whose failure would take down the service or lose data: load balancers, application servers, databases, message queues, and the network paths between them. The standard pattern is N+1, meaning you run one more instance than you strictly need so you can lose one and still serve full load. For higher tiers you go N+2 or spread copies across separate availability zones and regions.

The cost is real. Two of everything roughly doubles your infrastructure bill, and active-active setups add complexity because you must handle data conflicts, split-brain scenarios where two nodes both think they are the leader, and the latency of keeping copies in sync. Synchronous replication is safe but slow because every write waits for the replica; asynchronous replication is fast but can lose the last few writes if the primary dies.

Redundancy also fails silently if you never test it. A standby that has quietly been broken for months is worthless. This is why teams run failover drills and tools like Netflix's Chaos Monkey, which kills production instances at random to prove the redundancy actually works.