Shared dependencies make redundancy cosmetic — two systems…
When two systems appear redundant but share a common power source, network segment, authentication service, or human operator, treat them as a single point of failure with cosmetic duplication rather than genuine redundancy.
When This Fires
- Designing backup systems, disaster recovery, or high-availability architectures
- Evaluating whether existing "redundancy" is genuine or cosmetic
- After a failure where both primary and backup failed simultaneously
- During any resilience audit of personal or organizational systems
Common Failure Mode
Counting copies as redundancy: "We have two databases, so we're covered." Check: same physical host? Same cloud region? Same maintenance window? Same admin? If any of these are shared, the two databases provide cosmetic duplication, not genuine redundancy.
The Protocol
When evaluating redundancy: (1) List every dependency each redundant system relies on: power, network, auth, human operators, data, physical location, software dependencies. (2) For each dependency, check: do the redundant systems share it? (3) Any shared dependency is a common-mode failure point — a single event that defeats the redundancy. (4) For each shared dependency → either eliminate the sharing (separate power, separate network, separate operators) or accept that the redundancy is partial and the shared dependency is the true single point of failure.