We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Picture this: it is 2:47 AM. Your on-call phone rings. The entire application is down. Users see connection timeouts. You check the dashboard. CPU is fine, memory is fine, all three backend servers are healthy. Then you spot it: the crashed.
Traffic was flowing through a single load balancer because nobody set up a backup. One process panic, one kernel bug, one bad config push, and every user in your system lost service.
This is why load balancer failover exists. Not because your backends fail (health checks handle that). Because the load balancer itself can fail. And when the single point of entry dies, nothing else matters.
The good news: solving this is a well-understood problem. VRRP, keepalived, and cloud-managed load balancers have been doing automatic failover for decades. The bad news: most teams discover they need it only after the first outage.
Two load balancers share a virtual IP address. One is the master, the other is the backup. The master holds the VIP and handles all traffic. Both exchange heartbeats.
| Component | Role |
|---|---|
| Virtual IP (VIP) | Floating address that clients resolve to. Not tied to any physical machine. |
| Master LB | Currently owns the VIP. Forwards traffic. Runs backend health checks. |
| Backup LB | Receives heartbeats. Maintains config. Ready to claim the VIP instantly. |
| VRRP / keepalived | Protocol that manages VIP ownership. Gratuitous ARP claims the VIP in 1-2 seconds. |
| Backend pool | The servers receiving traffic. Sized at 2N+1 so one can die safely. |
The critical difference from failover: VIP failover happens below the DNS layer. No TTL propagation delay. The backup sends a gratuitous ARP, switches update their MAC tables, and traffic reroutes in 1-2 seconds. DNS failover takes minutes because TTL caches across the internet do not expire instantly.