A reliable system does not merely ask whether something can fail. It asks how much of the world is allowed to fail with it.
A fault domain is a bounded part of a larger system within which failures are expected to share consequences more strongly than they do across the boundary. The purpose is architectural: keep one local fault from becoming an estate-wide event.
This is a specialist branch beneath How Failure Works, How Redundancy Works and How Decoupling Works. Those roots explain failure, alternate paths and containment. Fault domains ask a narrower question: where should the boundaries sit so the blast radius stays bounded?
A Fault Domain Is Not Just a Box on a Diagram
Two servers in different racks are not truly independent if both rely on the same power distribution unit. Two buildings are not separate service domains if one identity provider, one database and one network path can disable both. Two teams are not operationally independent if one specialist is the only person who can approve both workflows.
Fault-domain design therefore follows shared dependencies backward. The boundary is real only when the supposedly independent parts do not collapse under the same single failure.
Blast Radius Is the Quantity We Are Trying to Bound
The blast radius is the scope of consequence produced by a fault. It may be one component, one rack, one train, one branch, one customer group, one district, one department or the whole organisation.
Good architecture does not pretend blast radius can always be zero. It designs so that the likely failure of one domain produces a consequence smaller than the whole system.
Independence Has Several Layers
- Physical: separate rooms, fire zones, racks, tracks or sites.
- Power: separate feeders, breakers, batteries or generators.
- Network: alternate switches, routes, carriers or communication paths.
- Software: isolated processes, clusters, tenants or service boundaries.
- State: corruption in one partition does not rewrite every copy.
- Identity and authority: one credential failure does not lock out every control path.
- Human: one person, team or supplier is not the only owner of every recovery action.
A domain can look separate at one layer and remain coupled at another. This is why redundancy without independence is fragile.
Fault Domains and Common-Cause Failure
If supposedly redundant parts share a hidden dependency, the same event can remove all of them at once. That is a common-cause failure.
Fault-domain design tries to make those shared dependencies visible before the failure. Later in this corridor, How Common-Cause Failure Works examines that mechanism directly.
The Boundary Must Match the Recovery Plan
A domain is useful only if the rest of the system knows what to do when it is lost.
- Can traffic be rerouted?
- Can another site accept the load?
- Can a train be removed without stopping the entire line?
- Can one customer partition be isolated without corrupting others?
- Can the organisation operate in a reduced mode while the domain is repaired?
The fault boundary and the failover path are therefore designed together.
Worked Example: Data Centre
A service runs across several machines. If every machine is in one rack powered by one circuit, machine redundancy does not protect against rack-power failure.
Distributing replicas across racks creates a larger fault domain. Distributing across independent halls or sites can create another. Each layer protects against a different class of failure.
The deeper lesson is that redundancy must be placed across the boundary of the failure you intend to survive.
Worked Example: Railway
A railway power system is divided into sections so a local electrical fault can be isolated rather than removing traction power from the entire network. Signalling, track circuits, platform systems and communications also use bounded zones and alternate paths for similar reasons.
The exact architecture varies by railway, but the principle is stable: design the network so local repair remains possible while unaffected areas continue operating.
The applied owner remains How MRT Works | It’s Mathematics.
Worked Example: Banking and Payments
A bank may isolate payment channels, customer segments, systems or operational regions so one fault does not automatically become a full-bank outage.
The danger is hidden coupling: one central identity system, one ledger dependency or one shared change can still bridge the domains. Resilience requires tracing the complete dependency graph rather than counting visible systems.
A Careful Analogy: Education
Curriculum design can also benefit from bounded failure thinking. If one weak prerequisite causes failure across five later topics, the learner’s knowledge structure contains a large “fault domain.”
Teachers can reduce the blast radius by making dependencies explicit, detecting gaps early and allowing alternate representations or repair routes. This is an analogy, not a claim that cognition is a server cluster.
A Careful Analogy: Institutions
Institutions also become fragile when every decision, permission or record depends on one office or one person.
Delegated authority, alternate sites, documented procedures and distributed records can reduce the organisational blast radius of absence, error or disruption — provided the copies remain coordinated enough to avoid conflicting state.
Too Many Fault Domains Can Create Coordination Cost
Partitioning everything aggressively is not free.
More boundaries mean more interfaces, state synchronisation, monitoring, reconciliation and operating complexity. A very small fault domain can reduce blast radius while increasing everyday coordination cost.
The design problem is therefore a trade: contain enough failure without fragmenting the system into an unmanageable number of islands.
A Fault-Domain Checklist
- Choose the failure class you want to survive.
- Trace every dependency shared by the supposedly independent parts.
- Define the maximum acceptable blast radius.
- Place redundancy across the fault boundary, not inside it.
- Test power, network, state, authority and human common causes.
- Define isolation behaviour when the domain fails.
- Define failover or degraded operation for the unaffected remainder.
- Exercise the failure to verify the boundary is real.
The CivDJ Rotation
- Forward: local fault → domain boundary → contained consequence → alternate path or repair.
- Backward: start from a system-wide outage and trace which supposedly separate domains shared one hidden dependency.
- Rotate: compare architecture, operations, finance, safety and receiver views of the acceptable blast radius.
A fault domain is architecture making a promise: this part may fail, but it should not be allowed to take everything else with it.
Continue through How Redundancy Works, How Decoupling Works and the master How X Works hub. Next: failover — how live function moves from a failed domain to a standby path without losing state or creating a second failure.