Blast-Radius Test¶

Impact-sizing test — instantiates Eventual-Occurrence Containment Design

Deliberately fails one component and measures how far the damage actually reaches — sizing the worst-case impact and exposing the shared dependencies that make the blast bigger than the diagram claims.

A containment diagram tells you where damage is supposed to stop. Blast-Radius Test finds out where it actually stops. It takes a single component, fails it on purpose, and measures the true extent of the fallout — how many users, services, transactions, or units are affected, and how far the effect propagates before something arrests it — then compares that measured reach against the boundary the design claims. Its distinguishing question is one of impact geometry: how bad, and how far. That sets it apart from the sibling that checks whether the defenses fire (Failure-Injection Test reads a different dial) and from the ones that estimate how likely the failure is (the probability mechanisms). The test's most valuable output is usually the surprise — the shared dependency nobody drew, which quietly lets a "contained" failure jump its fence.

Example¶

A multi-tenant SaaS platform believes its customer tiers are isolated: an outage in one tier should never touch another. To check, the reliability team runs a controlled blast-radius test in a staging replica — they hard-fail the primary region's shared metadata database and watch what degrades. The intended blast radius was "one region's write path." The measured blast radius is three times that: an authentication service in every region turns out to read tenant configuration from that same metadata store, so a failure meant to be regional silently degrades logins worldwide. The test converts a diagram's claim ("tiers are isolated") into a measured worst case ("≈40% of active customers see auth failures") and names the culprit — a shared dependency the architecture review had missed. The fix (give auth its own replicated config path) shrinks the radius before a real database failure ever exercises it.

How it works¶

The test starts from a single deliberate failure and traces the actual propagation rather than the intended one. It picks a component, removes or corrupts it under controlled conditions, and then follows the damage outward hop by hop — which downstream things break, and why — until it either hits the designed boundary or overruns it. Two numbers come out: the measured extent (the worst-case population or loss, which is what a consequence cap must actually bound) and the leak paths (the shared dependencies that carried damage past the fence). It is an empirical measurement of reach, not a calculation of odds and not an enactment of the boundary; it tells you how big the cap has to be and where the walls are really thin.

Tuning parameters¶

Failure-point selection — which component to break. Choosing adversarially (the worst plausible single failure) sizes the true worst case; choosing representative points is cheaper but can miss the ugly one.
Impact definition — what counts as "affected": fully down, degraded, or merely slower. A strict definition understates the radius; a loose one overstates it. Fix it before you run.
Test realism — staging replica versus production. Production gives the truest radius but risks a real outage; a replica is safe but only as faithful as its fidelity to the shared dependencies that matter.
Propagation depth — how many hops of knock-on effect to trace. Shallow tracing finds the obvious blast; deep tracing finds the second- and third-order couplings, at more effort.

When it helps, and when it misleads¶

Its strength is replacing a claimed boundary with a measured one and dragging hidden couplings into the light — the shared config store, the common power feed, the one library everything imports. Its failure modes are the mirror of that strength. It can only break the failure points someone imagined, so an unknown coupling survives untested and un-found. It invites blast-radius theater — measuring the radius, filing the number, and never actually reducing it. And it is easily run backwards: performed after an architecture is already chosen, framed to confirm "the blast is acceptable" rather than to challenge it. The discipline is to pick failure points like an adversary, and to pair every measured radius with a reduction target and a re-test — often by moving toward genuinely independent cells or bulkheads^[1] so a single failure has fewer places to spread.

How it implements the components¶

Blast-Radius Test realizes the sizing-and-spread slice of the archetype's consequence-control machinery — the parts a measurement can produce, not the parts it must trigger:

consequence_cap — it measures the worst-case impact of a single failure, which is exactly the magnitude any cap has to be set to bound; a cap set below the measured radius is fiction.
common_mode_dependency_check — its core discovery is the shared dependency that lets damage cross the intended boundary, defeating the isolation the design assumed.

It sizes and maps the blast but does not enact the isolation that stops it (Automatic Isolation Trip), model how likely the triggering failure is (Fault Tree with Repeated-Opportunity Branch), or keep critical functions running afterward (Degraded-Mode Runbook).

Instantiates: Eventual-Occurrence Containment Design — the test supplies the measured worst case and the leak paths that the containment layers must be sized and drawn against.
Sibling mechanisms: Failure-Injection Test · Automatic Isolation Trip · Degraded-Mode Runbook · Fault Tree with Repeated-Opportunity Branch · Cumulative Risk Horizon Table · Sentinel Event Monitoring · Recovery Drill and Restore Test · Probabilistic Safety Assessment · Repeated-Trial Probability Calculator · Opportunity Exposure Register · Post-Incident Recurrence Review · Stop-or-Scale-Back Gate

References¶

[1] Cell-based (or bulkhead) architecture partitions a system into independent compartments so that a failure is confined to one cell — a standard way to shrink a measured blast radius by removing the shared dependencies that let damage propagate. ↩