Blast radius

At a glance

Method	What it produces	What it misses
Traffic share of the target	A percentage of direct requests	Every service that depends on the target synchronously
Declared dependencies from a catalog file	A list someone wrote down	Anything added since the file was last edited
Single-hop observed dependencies	Immediate callers, from real traffic	Effects that propagate two or more hops
Graph traversal with criticality weighting	Affected services, ranked by how much they carry	Failure modes with no edge in the graph
Traversal over a time-versioned graph	The same, as the topology was at the moment in question	Nothing structural, but it costs dependency history to build

How it works

Given a proposed action on service X, the calculation walks outward from X across observed dependencies and asks, at each hop, what fails or degrades if X does. The result is a bounded statement rather than a score: if this fails, up to some share of checkout traffic and some share of notification delivery are affected.

Two properties of the graph decide whether that statement is trustworthy. The first is where the edges come from. Edges declared in a catalog file describe the system as someone last understood it; edges observed from live traffic describe the system as it is. The dependency nobody documented is precisely the one that turns a contained change into an outage.

The second is whether the graph is weighted. A flat list of connected services treats a batch job and the payment path as equals. Weighting by criticality, for instance by running PageRank over the observed call graph, gives a ranking that matches how a human would triage the same list.

The reason to compute this before an action rather than after an incident is that it can then be enforced. Each proposed action carries a predicted impact, a policy states the maximum permitted bound, and anything exceeding it is refused or escalated. That makes blast radius a gate rather than an advisory, which is the pattern set out in the Runtime Policy Patterns.

How it is measured

Blast radius is a prediction, so the measurement is calibration: how often the predicted scope matched the scope that actually occurred. That number is only available retrospectively, from incidents where a change did fail, and comparing the prediction against the postmortem is the check that keeps the graph honest.

Two failure directions matter differently. Undercounting is dangerous, because it lets through an action that should have been escalated, and it is the usual direction when the graph is built from declarations. Overcounting is merely expensive: it escalates changes that were safe, and a system that overcounts routinely gets its bound relaxed until it stops mattering.

The practical instrumentation is unglamorous. Record the predicted radius with every enforced decision, then join it to incident records later. Without that record there is no way to distinguish a bound that is working from one that has never been tested. The same trace is what turns alert triage prioritisation from a heuristic into something reviewable.

Common misconceptions

That a low traffic share means a small blast radius. A service handling three percent of direct traffic can be a synchronous dependency of one handling sixty. Direct share is the wrong denominator.

That it is a deploy-time concern only. Any action that changes production has one, including restarting a pod, rolling back, scaling down and rotating a credential. Agent actions are the case where this stopped being theoretical.

That the number is the deliverable. A figure on a dashboard changes nothing. What changes behaviour is a policy that refuses the action when the figure is too high, and an escalation path for the cases where a human should decide.