Redundancy Design

Redundancy design

Redundancy is expensive and frequently ineffective, because duplicated components often share a dependency that fails together. Useful redundancy is defined by what it makes independent.

Method

1. Identify the failure domain you are protecting against. Process, host, zone, region, or provider, since redundancy within a domain does not protect against that domain failing.
2. Check for shared dependencies. Two instances behind one database, one network path, or one credential fail together regardless of count (see failure-mode-analysis).
3. Match the level to the objective. Multi-region costs far more than multi-zone and is only justified by a target that requires it (see service-level-objectives).
4. Verify failover actually works. Standby capacity that has never taken traffic is an assumption (see disaster-recovery-testing).
5. Prefer active-active where possible. Standby paths that are never exercised are usually broken when needed.
6. Account for the coordination cost. Replication introduces consistency trade-offs that are a design decision rather than a detail (see consensus-basics).
7. Include the operational overhead. Redundant systems are more complex to operate and debug, which is part of the cost.

Boundaries

Redundancy addresses infrastructure failure and not bugs, which replicate perfectly to every copy. It increases cost and complexity proportionally. Some correlated failures such as configuration errors defeat redundancy entirely (see chaos-engineering).