High availability

Availability is commonly expressed as system uptime: the percentage of time during which the system is working and accessible.

For example, 99% uptime permits roughly 3.65 days of unavailability per year.

Availability can also be measured as a request success ratio:

availability = successful requests / total requests

Under this definition, 99% availability means that one request out of every hundred fails.

The reason may be a server bug, a response that misses its deadline, or a network outage that prevents the request from reaching the server.

Availability depends on who measures it.

During a network outage, servers may remain healthy and report 100% uptime. Clients still experience the system as unavailable because they cannot reach it.

The client’s experience is therefore more important than the server’s internal perspective.

Before agreeing on a target, clarify both the measurement and the observation point.

There is no universal percentage at which a system suddenly becomes highly available.

Practical 100% availability over an arbitrarily long period is not a realistic design target. Hardware faults, software faults, and human errors can combine into an outage.

Attempting to approach 100% also produces increasingly complex architecture and greater infrastructure and maintenance cost.

High availability is better understood as an architectural and operational property. The system must be designed, implemented, tested, and maintained with availability in mind.

Imagine a web application deployed to one production server. It runs for a full week without a failed request, so its measured availability for that week is 100%.

It is still not highly available. That server is a single point of failure. If it stops, the entire application becomes unavailable, with no defined recovery path.

High measured uptime may be temporary luck. High availability requires mechanisms and processes that continue to work when conditions change.

1. Build redundancy

Eliminate critical single points of failure by adding redundancy.

Depending on the system, this may involve regions, availability zones, fallbacks, data replication, or high-availability pairs.

2. Switch without losing data

The system must move traffic from one server to another safely.

Relevant concepts include DNS, load balancing, reverse proxies, API gateways, peer discovery, and service discovery.

3. Protect the system from clients

Clients may send too many requests, expensive requests, or inputs that trigger failures.

Common protection mechanisms include load shedding, rate limiting, shuffle sharding, and cell-based architecture.

4. Protect the system from dependencies

Dependencies can fail or become slow. Use timeouts, circuit breakers, and bulkheads to contain their effects.

Retries require their own policy. The system must know when to retry, how to retry, and when another retry would be unsafe.

5. Detect and recover

Monitor every relevant level of the architecture. Once a failure is located, isolate it and return the system to a healthy state—automatically when possible.

Systems are not static. Teams add features, fix bugs, respond to growing load, upgrade software, and apply security patches.

Processes allow those changes to happen without silently eroding availability.

Important practices include:

• reviewing and approving code and configuration changes;
• regularly testing functional and non-functional requirements;
• deploying frequently through an automated pipeline;
• rolling back quickly when errors are detected;
• monitoring utilization and adding capacity before demand exceeds it;
• maintaining and testing a disaster-recovery plan.

Incidents will happen. After an incident, perform an analysis that establishes the root cause and identifies preventive actions.

The purpose is not merely to explain the failure. It is to reduce the chance of the same failure happening again.

Before a major launch—and regularly afterward—conduct an operational readiness review.

The review evaluates the system’s operational state, identifies risks and blind spots, and assigns actions to close those gaps.

A game day validates the design and the team response. Simulate events such as sudden load, dependency failures, or network problems, then observe how both the system and the team respond.

Process discipline also depends on team culture. A checklist alone does not create a highly available service.

Architecture and process still need a measurable commitment.

A service level objective (SLO) defines the target level of service, such as a minimum availability value.

A service level agreement (SLA) is the commitment between a service provider and its clients. It may define compensation or another consequence when the commitment is missed.

Published uptime is a result of designing and operating for availability, but the SLO makes the expected result explicit and testable.