A failure domain is a boundary with the property that a single failure inside it can take out everything inside it and nothing outside it. Hardware gives you some of these boundaries: a process, a machine, a rack, a building, a geographic area, an administrative account. Your design creates others whether you meant to or not: a shared database, a shared configuration file, a deployment that ships to every instance at the same second, one dependency that every request touches. Blast radius is the measurement you take against those boundaries. Pick the failure you consider most likely rather than the worst one imaginable, then list what stops working when it happens, which users notice, and for how long. The result is usually uncomfortable, because components drawn far apart on a diagram often share a domain that the diagram does not show. That is the point of the exercise: it makes shared fate visible so you can decide whether to accept it, split it, or duplicate across it. You can now mark the failure domains on a design, name the blast radius of its most likely failure, and say which of them the requirements actually oblige you to reduce.
Blast radius is the scope of impact a system experiences when a given component or dependency fails, and containment-oriented design asks, for every dependency, how far damage propagates if it fails,…