Servers crash. Disks die. Data centres lose power. The question isn't whether components will fail — it's whether your service stays up when they do. That's what high availability is all about: designing so that a single failure is a shrug, not an outage.
What high availability means
High availability (HA) is an architecture designed to keep a service running with minimal downtime, even when individual components fail. It's measured in uptime "nines" — 99.9%, 99.99%, and so on — but the idea is simpler: no single failure should take you down.
The core principle: assume things will fail, and design so it doesn't matter. HA isn't about building components that never break — that's impossible. It's about arranging breakable components so that any one breaking doesn't bring down the whole.
The building blocks
| Block | What it does |
|---|---|
| Redundancy | Run duplicates, so a spare takes over |
| No single point of failure (SPOF) | Nothing whose failure alone = outage |
| Failover | Automatically switch to a healthy component |
| Load balancing | Spread traffic; route around dead servers |
| Health checks | Detect failures so failover can trigger |
Redundancy
The foundation: don't run one of anything critical. Two (or more) web servers, replicated databases, multiple availability zones. If one dies, another carries the load.
Eliminate single points of failure
A SPOF is any component whose failure alone takes everything down — a lone database, a single load balancer, one network path. HA work is largely a hunt for SPOFs: find the one thing that, if it died, would kill you, and add redundancy.
Failover
Redundancy only helps if traffic actually moves to the healthy component. Failover — ideally automatic, via load balancer health checks — is what makes a dead server a non-event instead of an outage.
Levels of availability
HA is a spectrum, and more costs more (each nine is roughly 10× harder):
| Approach | Roughly buys you |
|---|---|
| Single server | One failure = outage |
| Redundant servers + LB | Survive a server dying |
| Multi-zone | Survive a data-centre/zone outage |
| Multi-region | Survive a whole region going down |
You don't need five nines for a blog; a payments system might. Match the investment to what downtime actually costs you — chasing maximum HA everywhere wastes money.
HA vs disaster recovery
They're related but distinct:
- High availability keeps you running through failures (redundancy, failover) — minimal downtime.
- Disaster recovery is how you recover from a major catastrophe (backups, restore) — measured by RTO/RPO.
HA is "don't go down"; DR is "get back up after the worst." You want both, sized appropriately.
A monitoring connection
HA depends on detecting failures so failover can fire — that's what health checks do internally. But you still need external uptime monitoring from multiple locations: to verify the whole system (including the load balancer and failover itself) actually keeps users served, and to catch the rare case where everything redundant fails at once.
The bottom line
| In one line | |
|---|---|
| What | Designing so one failure isn't an outage. |
| Principle | Assume failure; arrange components so it doesn't matter. |
| Blocks | Redundancy, no SPOF, failover, load balancing, health checks. |
| How far | Match the nines to what downtime costs you. |
High availability is the art of building reliable systems out of unreliable parts. Remove the single points of failure, add redundancy with automatic failover, and size it to your needs — so when a component inevitably dies, your users never find out.
Related: Load balancing, disaster recovery (RTO/RPO), what is 99.9% uptime?.