Redundancy and Failover

Redundancy is the practice of duplicating critical components — servers, databases, network paths, even entire data centers — so that the failure of any single one does not take down the system. Failover is the mechanism that detects a failed component and automatically redirects traffic or responsibility to a healthy redundant copy. Together they are the primary tools for eliminating single points of failure (SPOFs): any component that exists in only one copy is, by definition, a place where a single hardware fault, software crash, or network partition can cause a full outage. High availability is achieved not by making individual components unbreakable, but by assuming they will break and ensuring the system as a whole keeps functioning when they do.

In an active-passive (or active-standby) setup, one instance handles all traffic while one or more standby replicas stay synchronized but idle, ready to take over if the primary fails. This is simpler to reason about — there is only ever one writer — but it wastes standby capacity and the failover itself takes time (detecting the failure, promoting the standby, updating routing), during which the system is degraded or unavailable. In an active-active setup, multiple instances serve traffic simultaneously, so capacity is fully utilized and the loss of one instance simply means the others absorb its share of load with no explicit failover step. Active-active is harder to build correctly, especially for stateful systems, because concurrent writers must agree on ordering and conflicts.

Failover depends entirely on accurate failure detection. Health checks are periodic probes — a load balancer or orchestrator pings each instance's health endpoint, or checks TCP connectivity, on a fixed interval. An instance is marked unhealthy after it fails a threshold number of consecutive checks (to avoid flapping on a single transient blip) and healthy again only after passing a similar threshold of successful checks. The interval and threshold values encode a direct tradeoff: aggressive checking detects failures faster but risks false positives from momentary slowness, while conservative checking is more stable but leaves traffic flowing to a dead instance for longer.

Redundancy applies at every layer, not just application servers: redundant network paths avoid a single switch or ISP link taking down connectivity; redundant power supplies and generators keep a data center running through a utility outage; redundant DNS providers prevent a single DNS outage from making a service unreachable even if the origin servers are healthy. Designing for redundancy means asking, for every component in the request path, 'what happens if this one thing disappears right now' — and ensuring the answer is never 'total outage.'