We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
2 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 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”
On December 7, 2021, the AWS us-east-1 region experienced a multi-hour outage that took down Disney+, Venmo, Slack, and dozens of other services. Companies running exclusively in us-east-1 had no option but to wait. Companies with geographic redundancy across us-east-1, us-west-2, and eu-west-1 rerouted traffic within minutes and kept serving users.
A single region gives you availability zone redundancy, which protects against a datacenter fire or a power failure in one building. It does not protect against a region-wide networking event, a botched control plane deployment, or a natural disaster that affects an entire metropolitan area. AWS, Azure, and GCP have all experienced region-level outages. The question is not whether your region will have an incident but when, and whether your architecture survives it.
Geographic redundancy distributes your system across two or more regions on different continents so that a failure in any single region does not take down the product. The cost is real (roughly 2x to 3x infrastructure spend), the complexity is real (cross-region , conflict resolution, data residency), and the payoff is the difference between a five-minute blip and a four-hour outage.
| Component | Role | Example |
|---|---|---|
| Global routing | Sends users to the nearest healthy region | Route 53 latency routing, Cloudflare Load Balancing |
| Regional compute stacks | Full application tier in each region, self-sufficient for reads and writes | EKS clusters, ECS services, or EC2 fleets per region |
| Cross-region data | Keeps data synchronized between regions | Aurora Global Database, DynamoDB Global Tables, Spanner |
| Health checking | Detects regional failure and triggers rerouting | Route 53 health checks, Cloudflare origin health |
| Capacity headroom | Each region sized to absorb traffic from a failed peer | N+1 capacity planning at 50% steady-state utilization |
The architecture works in two modes. In steady state, each region serves its local users with low . During a failure, the healthy regions absorb the failed region's traffic without any manual intervention. The transition between modes must complete faster than your SLO allows, which typically means under five minutes for tier zero services.