Failover / redundancy
Also known as: high availability, HA, RTO, RPO, active-passive, active-active, VRRP
Redundancy means having backup components so that when one fails, the system keeps running.
Failover is the automatic process of switching to those backups. Together they're the foundation of high-availability systems: whether for internet connections, servers, power supplies, or data centres.
Failover / redundancy, explained at three levels
At home
Redundancy means having a backup. If your home router fails, you have no internet: there's no redundancy. A business might have two internet connections; if one fails, the other takes over automatically. That automatic switch is failover.
At work
Critical business systems need redundancy so that a single failure doesn't cause downtime. Web servers run in pairs; if one fails, the other handles all traffic. Database servers have standby replicas. Internet connections have backup lines. Each layer of redundancy reduces the chance that any single failure brings the whole system down.
At home
Active-passive failover: the primary handles all traffic; the secondary sits idle until the primary fails. Active-active: both handle traffic simultaneously: if one fails, the other absorbs the load. Active-active provides better resource utilization and zero-downtime failover. RTO (Recovery Time Objective) is how long failover takes; RPO (Recovery Point Objective) is how much data loss is acceptable. Both must be defined per system.
At work
Network redundancy patterns: dual ISP connections with BGP failover, bonded WAN links (LACP), redundant switches with RSTP/MSTP loop prevention, and SD-WAN with application-aware path selection. Server redundancy: load balancers distribute traffic and detect failed servers, removing them from the pool. Database redundancy: primary-standby with automatic promotion (Patroni for PostgreSQL, MySQL Group Replication).
At home
Failover detection depends on health checks: the load balancer or failover manager probes the primary component (TCP check, HTTP health endpoint, ICMP ping) on a configured interval. Detection time + probe interval determines failover speed. Keepalived (Linux) uses VRRP (Virtual Router Redundancy Protocol) to float a virtual IP between servers: failover is sub-second when the active node fails.
At work
Multi-region active-active deployments in cloud (AWS multi-region, Azure paired regions, GCP multi-regional) provide geographic redundancy against data centre-level failures. Global load balancers (AWS Route 53 health checks, Cloudflare Load Balancing) route users to the nearest healthy region. Chaos engineering (deliberately injecting failures, as pioneered by Netflix's Chaos Monkey) tests whether redundancy actually works before a real failure exposes gaps.
Real-world examples
At home
Sophie's blog hosted on AWS uses two EC2 instances behind a load balancer. When one instance was terminated during an AWS maintenance event, the load balancer automatically stopped sending traffic to it. Her blog stayed online: she found out about the failure the next day from CloudWatch, not from users.
At work
Jerome's company has two ISP connections at their main office: 1 Gbps fibre (primary) and 500 Mbps cable (backup). Their SD-WAN appliance monitors both links continuously. When the fibre had an outage last quarter, the SD-WAN failed over to cable in under 2 seconds: users on video calls noticed a brief glitch but didn't disconnect.
Common confusions
- Backup means failover — A backup is a copy of data you can restore from. Failover is automatic switching to a redundant system. Backups address data recovery after a problem; failover addresses service continuity during a problem. You need both: failover keeps you running; backups protect against data corruption or ransomware.
- Cloud services are automatically redundant — Cloud providers build redundant hardware, but you must architect your application for redundancy. A single EC2 instance in one availability zone has no redundancy: if that AZ has an issue, you're down. You must explicitly use multiple AZs, load balancers, and auto-scaling to achieve high availability.
For analysts
RTO and RPO requirements are key inputs to IT architecture decisions that have major cost implications. BAs helping define business requirements for systems should quantify how much downtime and data loss is acceptable: these metrics directly size the redundancy investment needed.
History & origin
Redundancy principles in engineering predate computers, rooted in aviation and military systems where component failure has catastrophic consequences. In computing, RAID (1988) applied redundancy to disk storage. High-availability clustering emerged in the 1990s. Cloud computing brought redundancy to the software layer: active-active configurations, multi-region deployments, and auto-healing infrastructure. Modern cloud providers offer SLAs of up to 99.99% uptime by building redundancy at every layer: hardware, networking, power, and cooling.