High Availability and Redundancy

Things fail. A disk wears out, a data center loses power, a network cable gets cut, a piece of software crashes. In a big-enough system, running long enough, some component is always either failing or about to. High availability (HA) is the design goal of building systems that stay up anyway — not by preventing failures, but by tolerating them.

The trick behind high availability is redundancy: never rely on a single copy of anything critical. Run duplicates. If one copy fails, the others take over, and the people using the system never notice.

Think of a commercial plane: it has multiple engines, multiple hydraulic systems, multiple radios. Losing one engine does not end the flight, because nothing truly critical exists in only one copy. Cloud architecture works the same way.

Single Points of Failure

A single point of failure is any component whose failure takes the whole system down. One database server. One network connection. One power supply. Any of these, if it fails and has no backup, causes a complete outage.

Designing for high availability means systematically identifying every single point of failure and eliminating it — by adding a duplicate that is ready to take over the moment the primary fails. The process of switching to the backup is called failover.

Redundancy Across Availability Zones

In an earlier chapter you learned about availability zones — separate, isolated data center buildings within the same region. They share a region name but have independent power, cooling, and network connections, so a problem in one building does not affect the others.

Running copies of your system across multiple availability zones is the standard way to survive a single-building outage. If the data center in zone A loses power, the copies in zones B and C carry on. This is the most common form of redundancy in cloud deployments.

For even stronger protection, teams spread across multiple regions entirely — separate geographic areas — though this is more complex and is usually reserved for systems that cannot afford any regional outage at all.

Measuring Availability: The "Nines"

Availability is expressed as a percentage of time the system is up over a year. These percentages are called the nines, and the difference between them is larger than the numbers suggest.

99.9% availability — often called "three nines" — sounds high. But 0.1% of a year is about 8.76 hours of downtime. For a business that runs around the clock, that is a real problem: nearly nine hours offline per year.

99.99% availability — "four nines" — cuts that to roughly 52 minutes per year. Moving from three nines to four nines is not a small step; it typically requires a substantially more sophisticated redundant design.

99.999% — "five nines" — is about 5 minutes per year. This level is rare and expensive, reserved for systems where even brief downtime has serious consequences: air traffic control, financial settlement systems, emergency services.

Providers publish these targets as SLAs (service-level agreements) — contractual guarantees about uptime. When you design a system, you pick components whose SLAs match your availability requirement, and you stack redundancy on top where needed.