We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 9-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”
In February 2017, Amazon S3 went down for nearly 4 hours. The root cause was a single command that removed too many servers from a subsystem during planned maintenance. The cascading failure took down S3, which took down half the internet because thousands of services depend on S3 for serving images, configuration files, and static assets.
Failover is the mechanism that detects a failed primary and redirects traffic to a standby. It is the difference between a 4-hour outage and a 90-second blip. The three flavors (hot, warm, cold standby) trade cost for recovery speed, and the right choice depends entirely on how much each minute of downtime costs your business.
Every database, , and managed cloud service you use has failover built in at some level. Understanding how it works, where it breaks, and how fast it actually runs (versus what the marketing material claims) is the difference between trusting your architecture and hoping your architecture works.
| Standby Type | Infrastructure State | RTO (Recovery Time) | Cost Multiplier | Best For |
|---|---|---|---|---|
| Hot | Fully running, real-time | Seconds | 2x primary cost | Payments, healthcare, trading |
| Warm | Running at reduced capacity, periodic sync | 5-30 minutes | 1.1-1.25x primary | SaaS products, mid-tier APIs |
| Cold | No running infra, backups only | 1-4 hours | ~1.01x primary | Dev environments, batch jobs, archival |
Recovery Time Objective (RTO) is the maximum acceptable downtime. It determines which standby type you need.
Recovery Point Objective (RPO) is the maximum acceptable data loss. Hot standby with sync replication gives RPO near zero. Cold standby with nightly backups gives RPO of up to 24 hours.
The RTO and RPO together define the envelope. A payment processor needs RTO < 60 seconds and RPO = 0. A developer blog can tolerate RTO of 4 hours and RPO of 24 hours.