Failure Domain
A failure domain is the boundary within which a fault is contained, such as a process, rack, zone, or region, and it determines what fails together.
Definition
A failure domain is a set of components that share a common mode of failure, so a fault in one can affect all others inside the same boundary.
Context and scope
Used in architecture reviews to plan isolation, place replicas, and avoid correlated failure across zones, regions, or tenants.
Common misconceptions
- Replicas automatically create independent failure domains
- Availability zones eliminate correlated failure
- Failure domains matter only for physical infrastructure
Anti-patterns
- Placing all replicas on one host or in one zone
- Sharing a database or control plane across supposedly independent domains
- Assuming provider zones fail independently without evidence
Related concepts
Authoritative source
What a failure domain means
A failure domain is the scope that one fault can reach. A process is a small domain; a host, a rack, an availability zone, a region, and a cloud provider are progressively larger ones. The useful question is not “how many replicas do we have” but “what do these replicas share”. If three instances run on one host, they share a failure domain. If three zones depend on one control plane, they share a different one.
Shared fate
Failure domains are defined by shared fate, not by names on a diagram. Two services in different zones still fail together if they use the same database, the same identity provider, the same DNS zone, or the same deployment pipeline. Correlated failure is the norm during large incidents: a network control plane outage can make healthy compute unreachable. Map dependencies, including control planes and external providers, and ask what a single credential or configuration error could take down.
Mapping your domains
Start with the user journey, then trace every dependency. Note where state lives, how replicas are placed, and which components are managed by the same operator or vendor. Test the boundaries: terminate an instance, block a zone, revoke a credential. Injection experiments reveal whether the theoretical boundary holds in practice.
Designing within limits
Place replicas across independent domains, keep sufficient capacity in each, and avoid synchronous dependencies that force all domains to wait. Use bulkheads to stop one domain’s failure from consuming shared resources. Compared to simple duplication, deliberate domain design also accounts for the failure of the mechanism that performs failover.
Limits
Every architecture has a largest domain, and beyond it there is no redundancy. For example, a multi-region design still fails if both regions depend on one global certificate or one deploy pipeline. Accept the residual risk explicitly, document it, and test the recovery path that remains.