Blast Radius
Also known as: failure domain, impact radius
Blast radius is the extent of damage a single failure or change can cause — how many users, tenants, regions or services are affected when one component fails. Architecture decisions are largely blast-radius decisions: containment costs complexity, and every shared component enlarges the radius.
Last reviewed · Part of the Architecture Glossary
In practice
Name the radius before choosing the mitigation:
| Failure | Radius | Containment |
|---|---|---|
| One pod OOMs | One pod's in-flight requests | Replicas + health checks |
| A bad deploy | Every user, immediately | Canary + fast rollback |
| A poisoned shared cache | Every reader of that key | Namespaced keys, short TTL, versioned key prefix |
| One tenant's runaway query | Every tenant on that database | Per-tenant quotas, cell-based isolation |
| A region loses network | Every user in that region | Multi-region with independent control planes |
| An expired certificate | Every caller, everywhere | Staggered expiry + automated rotation |
The pattern the list points at is cellular architecture: partition users into independent cells, each with its own full stack, and deploy changes cell by cell. A failure caps at one cell's population. The cost is real — N times the operational surface — which is why it belongs to systems where a full outage is existential, not to every service.
When it matters
Deployment strategy, multi-tenancy design, shared-infrastructure decisions, and every review of a component that everything depends on.
Common mistake
Adding a shared service to reduce duplication without noticing it just made every consumer share a failure domain. A shared config service that everything reads at startup is a single point of failure with a friendly name.
See also
- Circuit BreakerA circuit breaker wraps calls to a dependency and stops making them once the failure rate crosses a threshold, failing fast for a cool-down period before letting a trial request through.
- Graceful DegradationGraceful degradation is the property of continuing to deliver core functionality with reduced features when a dependency fails, instead of returning an error.
- Canary ReleaseA canary release routes a small fraction of production traffic to a new version, compares its error and latency metrics against the stable version, and promotes or rolls back based on the result.
- Hot PartitionA hot partition is a single shard receiving a disproportionate share of traffic, so it saturates while the rest of the cluster idles.