Failover: Automatic Recovery When Things Go Wrong
Failover is your system's automatic plan B. When a primary component fails, a standby takes over instantly without human intervention. It's essential for high-availability systems. The footgun is assuming the standby is perfectly in sync; it might not be.
WHY IT EXISTS Systems fail. Hardware breaks, software has bugs, and networks go down. Failover exists to minimize or eliminate the user-facing impact of these inevitable failures by having a backup ready to go automatically. Without it, any single failure could cause a complete outage requiring manual intervention.
THE MENTAL MODEL Think of failover like the emergency power generator for a hospital. The main power grid is the primary system. If it fails, sensors detect the outage and automatically start the generator (the standby system) to take over the load. The goal is a seamless transition so critical operations continue uninterrupted. The key is that it's automatic; a manual switch would be a 'switchover'.
HOW IT WORKS A failover system continuously monitors the health of the primary component, often using a 'heartbeat' signal. If the heartbeat stops, the monitoring system declares the primary dead and triggers the switch. This involves redirecting traffic (like updating DNS or IP addresses) to the standby server, which then becomes the new primary.
WHEN TO USE IT Use failover for any stateful or critical service where availability is more important than the cost of redundancy. Common examples include primary databases in active-passive clusters, network load balancers, and critical application servers. It's for services where even a few minutes of downtime is unacceptable.
WHEN NOT TO USE IT Avoid failover for stateless services that can be easily replaced by a load balancer spinning up a new instance. If the cost of maintaining a fully redundant, synchronized standby system outweighs the business cost of a brief outage, a manual switchover might be sufficient. If a brief, planned outage is acceptable, you may not need it.
ONE CANONICAL EXAMPLE A common database setup is an active-passive cluster. The active database handles all requests while constantly replicating its data to a passive, standby database. If the active database server fails, the system automatically promotes the passive server to become the new active one and redirects all application traffic to it, minimizing data loss and downtime.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.