Cloud and DevOps
High availability
High availability is the practice of keeping a service running through failures by removing single points of failure and failing over to a healthy copy.
Teams design for high availability when an hour of downtime costs more than a second copy of the system. The question is simple: when a server, a disk, a zone or a deployment fails, does the service keep running without anyone being paged?
Why does high availability matter?
- Revenue and trust. An unavailable checkout is lost sales; an unavailable API is a customer’s outage too.
- Operations. A system that fails over by itself lets the on-call engineer fix the root cause in the morning.
- Deploys. The same redundancy lets a CI/CD pipeline roll out a new version one server at a time with no downtime.
How is availability measured?
| Availability | Downtime per year | Downtime per month | What it rules out |
|---|---|---|---|
| 99 percent | 3.65 days | 7.3 hours | Nothing; manual recovery is fine |
| 99.9 percent | 8.8 hours | 44 minutes | Single servers without failover |
| 99.99 percent | 52 minutes | 4.4 minutes | Any manual step in recovery |
| 99.999 percent | 5.3 minutes | 26 seconds | Single-region designs |
Availability is uptime divided by total time, measured against a definition of “up” such as “the health endpoint answers within a second.” Each nine costs roughly ten times the previous one, so pick the target from the business need.
What are the parts of a highly available system?
- Redundancy. At least two of everything that can fail: two app servers, two zones, a primary and a standby database.
- A load balancer. Spreads traffic across the healthy copies and gives clients one address that does not change when a server dies.
- Health checks. The load balancer and the orchestrator probe each instance and stop sending traffic to one that fails.
- Failover. The automatic switch from a failed component to its standby: promoting the replica database, moving a virtual IP, rescheduling a pod.
- Replication. Keeps the standby current. Synchronous replication loses no data; asynchronous is faster but can lose the last few writes.
- Stateless services. App servers or microservices that keep nothing locally can be replaced freely; state lives in the replicated database.
How do you read a high availability diagram?
Start at the users. In the diagram at the top of this page they reach one address, the load balancer, which health checks four app servers, two in each availability zone. A zone is a separate building with its own power and network, so a zone failure takes out two servers and the load balancer stops routing to them.
Below the servers is the database tier. The primary in zone a takes all writes and replicates to the standby in zone b. If the primary fails, the dashed failover arrow shows the standby being promoted, and the dashed lines from the zone b app servers show them switching to it. Nothing in the picture exists only once, which is the test: cover any single box with your thumb and the service should still answer.
How does high availability compare with fault tolerance and disaster recovery?
- Fault tolerance means a component fails and nothing is interrupted, not even for a second. It takes redundant hardware and is reserved for parts that cannot blip, such as storage controllers.
- High availability accepts a short interruption, seconds to a minute, while traffic moves to a healthy copy inside one region.
- Disaster recovery covers the loss of a whole region or site, with a second region, backups and a runbook, and takes minutes to hours.
A system usually needs all three at different scopes: redundant disks in a database server, two zones for the service and a second region for the disaster plan.
How do you design for high availability?
- Set the target. Pick the nines from the business impact of downtime and write down what “up” means.
- Map the system. Draw an architecture diagram of every component in the request path, including DNS, queues and third-party APIs.
- Find the single points of failure. Ask what happens if each box disappears.
- Add redundancy and failover at each one, starting with the database, which is usually the hardest.
- Spread across zones. Put every tier in at least two availability zones, defined in infrastructure as code so they match, which is how a cloud computing architecture is meant to be used.
- Make services stateless so an orchestrator such as a Kubernetes architecture can replace instances at will.
- Test the failover. Kill a server, then a zone, on purpose and on a schedule. A failover that has never run has never worked.
- Watch it. Observability with alerts on error rate and latency tells you a failover happened and whether it worked.
What are common high availability mistakes?
- Redundant servers, single database. The most common single point of failure.
- Untested failover. The standby has been broken for months, which you learn during the outage.
- Forgetting the small things. One DNS provider, one expiring certificate, one person who knows the password.
- Health checks that lie. A check that only confirms the process is alive, not that it can reach the database, keeps routing traffic to a server that returns errors.
- Correlated failures. Two “redundant” servers on the same host, or two zones that share a dependency, fail together.
What tools help with high availability?
- Managed cloud services. Multi-zone load balancers, managed databases with automatic failover and container platforms that reschedule failed instances, from any major provider.
- Orchestration and chaos engineering tools. An orchestrator to reschedule workloads and chaos tools that inject failures on a schedule to prove the failover works.
- AI diagramming tools. Tools like Eraser turn a description of your zones, tiers and failover paths into an architecture diagram, or draw it from your cloud account with an AWS diagram generator, so single points of failure are visible before an outage finds them.
For more on this kind of diagram, see architecture diagrams.
Frequently asked questions
-
What does 99.99 percent availability mean?
It means the service may be down for about 52 minutes a year, or roughly one minute a week. Each extra nine divides the allowed downtime by ten: 99.9 percent is 8.8 hours a year, 99.999 percent is 5 minutes. The cost rises steeply with each nine because the higher targets rule out any manual recovery step.
-
What is a single point of failure?
A single point of failure is any component whose loss takes the whole service down because nothing else can do its job: one database server, one load balancer, one network link, one region. High availability work is mostly finding these and adding a second copy with automatic failover, then testing that the failover actually works.
-
What is the difference between high availability and disaster recovery?
High availability handles small, frequent failures inside one region automatically and in seconds, with redundant components and health checks. Disaster recovery handles the loss of a whole region or data center, usually with a second region, backups and a runbook, and recovery takes minutes to hours. You need both; one does not replace the other.
-
Does running in two availability zones make a system highly available?
Only if every tier is in both zones and traffic can move between them automatically. Two zones of app servers with a single database in one zone still has a single point of failure. Check each component in turn: what happens if this zone disappears, and does anything need a human to recover?
