Resilience and Redundancy
Resilience is the ability to keep operating through failures and attacks; redundancy, done well, is one way to achieve it.
Surviving the Inevitable
Components fail, networks drop, and attacks land. Resilience is the property of continuing to deliver essential function despite these events, and recovering gracefully afterward. It is a broader goal than prevention: rather than assuming nothing bad happens, it assumes bad things will and designs so they do not become catastrophic.
Redundancy
Redundancy provides spare capacity so that the loss of one element does not stop the whole. It comes in patterns such as N+1 (one spare beyond need), 2N (a full duplicate), and geographic distribution (copies in separate locations). Redundancy is the most direct route to resilience, but only if the redundant elements fail independently.
The Common-Cause Trap
- Two identical components share the same design flaw and fail together
- Backup power on the same feed as primary power fails in the same outage
- Redundant servers in one room are lost to one fire or flood
- A shared dependency, DNS, a certificate, a library, takes down every copy at once
Diversity Defeats Common Cause
Diverse redundancy uses different implementations for the same function, so a single flaw cannot disable all copies. In safety-critical control, diverse channels, different hardware and logic computing the same protection, guard against the correlated failures that plain duplication misses.
Fusion Context
A fusion plant's protective and control functions require both redundancy and diversity so that no single failure, and no single common cause, removes protection. The Hyperion breeder and burner designs specify independent, diverse safety channels precisely so a shared flaw cannot defeat them together. Resilience here also means graceful, fail-safe behavior: when capacity is lost, the machine moves toward its safe state rather than an unknown one.