The "Too Big to Fail" Fallacy
Think of a hospital with one giant generator powering every room. If that generator fails, every patient — from the waiting room to the ICU — loses power simultaneously. A better design uses separate, isolated power circuits so that a failure in one wing never touches the others. Cloud architecture faces the exact same problem.
In traditional cloud architectures, teams build massive, shared resources because it feels efficient:
- One giant database for all customers.
- One giant fleet of API servers.
- One giant queue.
The Risk: If a "Poison Pill" (a malformed request that triggers a bug) hits your system, or if a "Noisy Neighbor" (a customer generating extreme load) saturates a shared resource, they take down the entire shared resource. 100% of your customers go offline. The shared resource that felt efficient becomes a single point of catastrophic failure.
The Solution: Isolation
To reach 99.999% availability (roughly five minutes of downtime per year), we must accept that failure will happen and shift our focus from preventing failure to Blast Radius Reduction: when something breaks, how many customers are hurt?
| Architecture | Blast Radius |
|---|---|
| Monolith | ~100% — everything fails together |
| Availability Zones (3 AZs) | ~33% — one AZ fails |
| Cell-Based Architecture (20 cells) | ~5% — one cell fails |
The goal is not to build a system that never fails. The goal is to build a system where failure is boring — contained, predictable, and survivable.