Fault domain
A set of resources expected to be affected by the same underlying failure.
Also called: Failure domain, Blast radius
In practice
Drawing a fault domain is an act of prediction: you are asserting that these things will fail together and those things will not. The boundary can be a cabinet, a row, a power path, a cooling system, a hall, a site or a region, and the right one depends entirely on what the service needs to survive.
Useful boundaries match how failures actually propagate, which is often not how the estate is organised. Two racks in different rows can share a power path; two availability zones can share a fibre route; two services on different hosts can share a management network or a control plane. A boundary drawn on an inventory sheet rather than on the dependencies is a boundary that will be crossed during an event.
The value appears in placement decisions. Once domains are named, spreading the instances of a service across them becomes a checkable requirement instead of an intention, and the awkward cases surface early — replicas that ended up in the same cabinet, a standby that depends on the same cooling system as the primary.
Domains are also nested. A cabinet sits in a row, which sits in a hall, which sits in a site. Stating which level a given design protects against is more informative than saying it is redundant, because it says precisely which failures are covered and which are not.
Scope of this definition
This is an educational summary of how the term is used in data center practice. It is not a standard, a specification or engineering advice, and where a real decision depends on it, the current adopted standards, verified site information and qualified professional review are the correct sources.