Blast Radius Analysis

The exercise turns an abstract commitment to resilience into a specific list of design decisions, and it consistently produces surprises.

The method is mechanical. For each component: if this fails entirely, which user journeys stop, which customers are affected, what data is at risk, and how long until recovery. Then the harder version: if this is compromised rather than merely down, what can be reached from it.

The findings that recur across organisations. A shared component — an identity service, a configuration store, a feature flag service, a shared database — sits inside the blast radius of everything, so its availability requirement is higher than any individual consumer's and is usually not set that way. A "non-critical" service turns out to be a synchronous dependency of checkout. And a single account, cluster or region holds far more than the risk register suggests.

The design responses that reduce it: cells, so a failure affects a fraction of customers; graceful degradation, so a component's failure removes a feature rather than the service; asynchronous boundaries, so a dependency's outage delays rather than fails; and separate accounts or clusters per environment and tier.

The reporting value is that blast radius is a concept executives understand without translation. "This component's failure stops 100% of revenue" secures investment that "we should improve resilience" does not.