Redundancy
Redundancy duplicates components or capacity so the system survives failure, but it only helps when copies fail independently and failover works.
Definition
Redundancy is the provision of duplicate components, capacity, or paths so that the loss of one does not remove the service.
Context and scope
Applied to stateless instances, databases, network paths, power, and entire regions, using active-active or active-passive arrangements.
Common misconceptions
- More replicas always mean more reliability
- Redundancy removes the need for backups
- Active-passive is inherently safer than active-active
Anti-patterns
- Duplicating components that share the same dependency or credential
- Adding replicas without ever testing failover
- Treating redundancy as a substitute for fixing the root cause
Related concepts
Authoritative source
https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html
Forms of redundancy
Redundancy can duplicate running instances, standby databases, network links, power feeds, or whole regions. Active-active configurations use all copies at once and split traffic; active-passive configurations keep a standby ready to take over. Stateless services are easy to duplicate; stateful systems require replication, which introduces lag, conflict handling, and consistency trade-offs.
Independence is the point
Duplicated components only improve reliability when their failures are uncorrelated. Two servers in one rack share power and network. Two replicas using the same credentials share a revocation event. Two regions fed by one deployment pipeline share a bad release. Redundancy must be evaluated against failure domains: what does a single fault still take down?
Cost and complexity
Every copy costs money, and more copies mean more coordination. Replication adds latency and operational work; active-active writes require conflict resolution or partitioning. Compared to a single well-tested instance, redundancy improves availability but can reduce clarity: failures become partial, and debugging spans replicas. Keep the design as simple as the reliability target allows.
Redundancy is not backup
Replicas protect against component failure, not against deletion, corruption, or ransomware that propagates. Backups preserve history and allow point-in-time recovery. A replicated database will faithfully replicate a dropped table.
Testing
Failover must be exercised, not assumed. For example, a team may run three replicas but never notice that the load balancer still routes to the dead one. Remove a replica, drain a zone, and measure whether capacity and latency remain within target.
Limits
Redundancy cannot protect against bugs present in every copy or against correlated infrastructure failures. Beyond the largest affordable failure domain, teams must rely on graceful degradation, fast recovery, and explicit risk acceptance.