We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
6 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 8-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”
When AWS us-east-1 went down for multiple hours in December 2021, two groups of companies emerged. Netflix, Spotify, and a handful of others kept running because they had invested in multi-region active-active architectures. Everyone else, including some of the biggest names in SaaS, went dark until AWS fixed the problem.
High availability is not a feature you bolt on. It is an architectural decision that affects every layer of your system: load balancing, application deployment, database replication, DNS, session management, and monitoring. Each layer introduces potential single points of failure, and a single weak link in the chain determines your real availability, regardless of how redundant the other layers are.
The investment is not small. Running a system at 99.99% availability (52 minutes of downtime per year) costs roughly 5x more in infrastructure and engineering than running it at 99.9% (8.7 hours per year). The decision to pursue high availability should come from a concrete business calculation, not from a desire for architectural purity.
A system is only as available as its least redundant component. The HA audit asks one question at every layer: what happens when this thing dies?
| Layer | Single Point of Failure | Fix |
|---|---|---|
| One DNS provider | Multi-provider DNS (Route 53 + Cloudflare) | |
| One LB instance | Managed LB (AWS ALB) or active-passive LB pair | |
| Application | One instance | 3+ instances across 2+ AZs |
| Database | One primary | Primary + sync replica with automatic failover |
| Cache | One instance | Redis Sentinel or ElastiCache Multi-AZ |
| External dependency | One payment provider | Fallback processor (Stripe primary, Adyen fallback) |
| Region | One AWS region | Multi-region active-active or active-passive |
Most outages trace back to a component that the team assumed was redundant but was not. The classic example: a load balancer distributes traffic across 10 app instances, but the load balancer itself runs on a single node. The 10 instances give you zero benefit when the LB dies.