Documentation / Platform glossary / Blast radius
Blast radius is the extent of what breaks when one thing fails — how many users, tenants, or capabilities are affected. Reducing it is a design decision made in advance, because containment cannot be improvised once an incident is already spreading.
The term borrows from engineering and asks a specific question: given a failure at a particular point, what else stops working? A failure confined to one non-essential feature has a small blast radius. A failure that takes down a shared component every request depends on has a large one.
Several boundaries limit propagation. Tenant boundaries keep one customer's problem from becoming everyone's. Service boundaries keep a failing component from cascading, provided callers degrade rather than block. Deployment boundaries — staged rollouts, canary releases — limit how many users a bad change reaches before it is detected. Rate limits and quotas stop one consumer exhausting shared capacity.
Change is the origin of most incidents, which makes deployment boundaries more consequential than they first appear. A defect released to every customer simultaneously has the maximum possible blast radius even if the underlying bug is trivial, whereas the same defect released to a small cohort is a contained event.
The counterintuitive implication is that a system which fails in small ways regularly is often more dependable than one which fails rarely and completely. Reliability is about the distribution of failure, not only its frequency.
Blast radius is what an architecture reviewer is really asking about when they ask about resilience. Recovery speed matters, but scope determines whether an incident is a contained event or a company-wide one.
It also reframes severity usefully during an incident: knowing the boundary a failure is confined within tells responders how urgent it is and who needs to be told.
QueryTek treats containment as a design goal, using tenant boundaries to limit how far operational problems travel and staged delivery to limit how far a change reaches before problems surface. Infrastructure topology and deployment mechanics are not published.
