Failover
/ˈfeɪl.oʊ.vɚ/ · Noun · Development · Origin: 1985
Definitions
Failover is the automatic or manual process of switching to a redundant system, server, network, or component when the primary one fails, ensuring continuous service availability. In a failover configuration, a standby system monitors the health of the primary system (through heartbeats or health checks) and takes over its role when a failure is detected. Database failover might promote a read replica to become the new primary. Server failover reroutes traffic from a failed server to a healthy one. DNS failover updates records to point to backup infrastructure. Failover can be hot (standby is running and synchronized, enabling near-instant switchover), warm (standby is running but needs to catch up on recent data), or cold (standby must be started and configured before taking over). Automatic failover reduces downtime but risks false positives (triggering unnecessarily) and split-brain scenarios (both nodes believing they are primary). Testing failover regularly through chaos engineering and planned drills is essential because untested failover mechanisms frequently fail when actually needed.
In plain English: When the main system breaks, a backup automatically takes over so users barely notice anything went wrong.
Example: "The primary database crashed at 3 AM but failover kicked in within 8 seconds — users saw a brief blip and that was it."
Origin Story
The backup plan that kicks in when your primary system dies
**Failover** as a concept emerged from fault-tolerant computing in the 1960s and 1970s, particularly in Tandem Computers' **NonStop** systems designed for banking and telecommunications. The term describes automatically switching to a standby system when the primary fails.
There are two flavors: **active-passive** (standby waits idle until needed) and **active-active** (both systems handle traffic, absorbing the other's load on failure). Active-active is harder to build but wastes no capacity sitting idle.
The tricky part of failover is detecting failure accurately. Too sensitive and you get false failovers (split-brain scenarios); too slow and users experience downtime. Health checks, heartbeat protocols, and quorum-based consensus help, but failover remains one of the hardest problems in distributed systems.
Coined by: Tandem Computers / fault-tolerant computing community
Context: 1970s-1980s, fault-tolerant computing
Fun fact: Tandem Computers' NonStop systems were so reliable that banks and stock exchanges ran them for decades. The company's founder, James Treybig, was an early advocate of the idea that hardware will always fail -- the question is whether the system survives it.