Redundancy, high availability and fault tolerance are related ideas, but they are not interchangeable. Understanding the difference helps prevent designs that look resilient on paper yet still fail as one system.
1) Redundancy
Redundancy means having more than one component or path. Examples include dual power supplies, two network links, replicated servers or multiple data copies.
Redundancy is a building block, not a guarantee. The duplicate component must be independent enough, correctly configured and available when needed.
2) High availability
High availability is an operating objective: keeping a service available through expected component failures and maintenance. It usually combines redundancy, monitoring, automated or documented failover and tested recovery.
A high-availability design accepts that components fail and focuses on reducing service interruption.
3) Fault tolerance
Fault-tolerant systems continue operating with little or no visible interruption when a defined component fails. They often require simultaneous duplicate processing, synchronized state and rapid failure detection.
Fault tolerance can be expensive and complex. It is usually reserved for workloads where even a short interruption has serious consequences.
4) Practical comparison
| Concept | Primary aim | Typical example |
|---|---|---|
| Redundancy | Provide an alternate component | Two network links |
| High availability | Limit interruption | Cluster with automatic failover |
| Fault tolerance | Continue through failure | Duplicate synchronized processing |
5) Shared dependencies defeat apparent redundancy
Two servers may share one storage array. Two internet providers may enter the building through one conduit. Two cloud applications may rely on the same identity provider. These are common-mode dependencies.
A resilience review should trace each supposedly independent path all the way to its upstream facility, provider, account and control system.
6) Failover must be tested
A standby component may be outdated, misconfigured or unable to handle full load. Testing should verify detection, decision-making, technical failover, data integrity and return to normal operation.
The test result should record actual interruption, unexpected dependencies and corrective actions.
7) Choosing the right level
- Define the business impact of interruption
- Set a realistic recovery time objective
- Identify the failure scenarios in scope
- Compare the cost of resilience with the cost of downtime
- Document what remains outside the design
Operational review questions
Use these questions to connect the concept to a real service or environment:
- What failure scenarios is the design intended to tolerate?
- Which common-mode dependencies remain?
- How quickly is failure detected and who authorizes failover?
- Can the standby path carry full priority load?
- What did the most recent test reveal?
Related guides
What Failure Domains Mean in Digital Infrastructure
A plain-language explanation of failure domains, fault isolation, blast radius, and how infrastructure systems are designed to limit outages.
ResilienceBackup vs Replication vs Disaster Recovery
A practical comparison of backups, replicas and disaster recovery, including what each protects, what it does not protect and how recovery should be tested.
Network & DeliveryAnycast Routing Explained — Why CDNs and DNS Work So Fast
A plain-language explanation of anycast routing and why it allows DNS providers, CDNs, and global platforms to deliver traffic from the nearest location.
Compute & StorageConsistency vs Availability Explained
A detailed, plain-language explanation of consistency vs availability in distributed systems, including trade-offs, real-world examples, and why systems cannot maximize both.