Availability, SLAs, SLOs and the Nines

Availability is one of the most basic requirements in system design: the ability of a system to keep working, without unplanned downtime, for long periods, so users get service whenever they need it. Everyone claims to be "highly available"; this page makes it precise. Availability is measured as a percentage of time, usually quoted in "nines", and teams make it concrete with SLIs (what they measure), SLOs (the targets they set) and SLAs (what they promise customers).

Think of a pizza place. If it's open whenever you expect it to be and serves you a pizza whenever you want one, it is highly available. For a computer system, it means the system is up and usable whenever it's needed.

Measuring availability

Availability is the percentage of time a system is operational and serving as expected. A pizza place open 24/7 all year would be 100% available; in computing, 100% is effectively impossible.

Availability (%) = (Operational time / Total time) × 100

1. Choose the total time you're evaluating: a day, week, month or year.
2. Add up the downtime in that period: crashes, maintenance, network problems.
3. Compute operational time: total time − downtime.
4. Divide operational time by total time and multiply by 100.

Example: over one year (365 × 24 × 60 = 525,600 minutes) a system was down for 500 minutes in total.

Operational time = 525,600 − 500 = 525,100 minutes
Availability     = 525,100 / 525,600 × 100 ≈ 99.905%

Measuring from the user's side is better still: count the share of requests that succeeded quickly enough (an SLI), not just whether servers were up.

The nines: what counts as "high" availability?

Is 99.905% good? Availability is usually discussed in nines. "Five nines" (99.999%) is like a pizza place that is closed only about five minutes a year. That is genuinely highly available.

Each extra nine costs roughly an order of magnitude more engineering. Five nines leaves no time for a human even to notice a problem, so it requires fully automated failover. How many nines do you need? That depends on what you have promised, which is where SLAs come in.

Service level agreements (SLAs)

An SLA is a formal, written agreement between a provider and a customer that sets the level of service the provider will deliver. It names specific metrics and targets, such as uptime, response time and time to resolve issues, and the remedy if they are missed. For example, an SLA might promise 99.9% uptime, with service credits (a partial refund) if the provider falls short.

SLAs matter because they set clear expectations on both sides, give a standard for measuring the service, and spell out what happens when it isn't met. Every major cloud publishes them per service: Google Cloud, AWS and Azure all list uptime targets and compensation.

Google Compute Engine's SLA is a good example. It promises a different monthly uptime depending on how you deploy, and pays financial credits, calculated per calendar month, when Google misses the target:

Notice the gap: one VM gets 99.5% (about 3.6 hours of downtime a month), while the same VMs spread over several zones get 99.99% (about 4 minutes). The provider is pricing in exactly the redundancy described below.

Availability isn't the only thing an SLA can promise. Durability, the chance that stored data is never lost, is another. Amazon S3 is designed for 99.999999999% (eleven nines) durability: if you store 10,000,000 objects, you can expect to lose one about once every 10,000 years. See object storage.

SLI, SLO, SLA and error budgets

• SLI (service level indicator): a measured ratio of good events to total events, for example "successful requests that completed within 300 ms ÷ all requests".
• SLO (service level objective): the internal target for an SLI over a window, for example "99.9% of requests are good over 30 days".
• SLA (service level agreement): the contractual promise, with penalties. SLAs are set looser than SLOs so the team has a safety margin.
• Error budget: 100% − SLO. At 99.9% you may "spend" 0.1% of requests on failures each month. While budget remains, ship features; when it runs out, prioritize reliability. This turns availability into a shared, measurable trade-off instead of an argument.

How to achieve high availability

High availability means continuing to operate when things fail. Failures come in two kinds:

Expected failures are handled with redundancy: run the service across multiple zones or regions, load balance stateless servers, and fail over automatically.

Redundancy: availability zones and regions

Redundancy means having backup resources, such as spare servers or database copies, ready to take over when the primary fails. In the cloud it is organized around two units:

• An availability zone (AZ) is a separate location inside a cloud region, with its own power, cooling and network, isolated from failures in other zones. If one zone fails, work moves to another zone in the same region.
• A region is a geographic area made of several isolated zones. Regions operate independently, so a problem in one doesn't affect another, and deploying in several also puts you closer to users.

Deploying across multiple zones in a region removes single points of failure. Deploying across multiple regions goes further and survives large-scale events, such as a natural disaster or a region-wide outage. See geo-replication and disaster recovery.

Load balancing

A load balancer spreads traffic over many servers so none becomes an overloaded bottleneck. In the cloud, balancers can span a single zone, several zones or several regions; when a server or a whole zone fails, the balancer sends traffic to the healthy servers or zones that remain.

Data replication

Replication keeps copies of the data on different database servers. If the primary fails, a replica takes over and the system keeps its data. Replicas can live in the same zone, in other zones or in other regions, each step adding protection.

Health monitoring and automatic recovery

Health monitoring checks servers and components continuously; when it detects a failure it starts recovery automatically, for example restarting a service or failing over to a standby. Cloud providers offer this as a service: Amazon EC2 Auto Recovery recovers an instance when the underlying hardware is impaired. See health checks and failover.

More techniques

• Removing hard dependencies: cache data so reads survive a database blip, use queues so writes survive a slow consumer, and degrade gracefully when an optional dependency fails.
• Resilience patterns: timeouts and retries with backoff, circuit breakers, load shedding and rate limiting to stop overload cascading.
• Safe change: most incidents start with a change, so canary deployments, feature flags and fast rollback buy more availability than extra hardware.
• Fast detection and recovery: availability ≈ MTBF / (MTBF + MTTR). Halving the time to recover (MTTR) helps as much as halving how often things fail (MTBF), and is usually cheaper.

How availability composes

Components in series (each request needs all of them) multiply availabilities, so the total is lower than the weakest part. Components in parallel (redundant copies, any one is enough) multiply failure probabilities, so the total is far higher.

Parallel redundancy only helps when failures are independent. Two replicas in the same rack, deployed with the same bad config, or depending on the same DNS provider, fail together. Most big outages are correlated failures: a bad deploy, an expired certificate, a shared dependency.

Tech stacks for high availability

In an interview you won't be expected to go deep on products, but knowing the common ones keeps your answer concrete instead of hand-waving.

Open source

• HAProxy: a free, high-availability load balancer and proxy for TCP and HTTP, used by high-traffic sites such as Twitter, Airbnb and GitHub. It spreads work across servers to maximize throughput and minimize response time, and fails over automatically: if a server dies, traffic goes to the rest.
• Keepalived: load balancing and high availability for Linux. Load balancing uses the kernel's Linux Virtual Server (LVS, via IPVS); high availability uses the VRRP protocol to move a virtual IP between machines, so a standby takes over when the active load balancer fails. Its health checks monitor the real servers and change the LVS topology, adding or removing servers from the pool.

Cloud providers

Availability vs fault tolerance

The two are related, and together they make a system reliable:

• Availability measures uptime: the share of time a system is operational and serving as expected.
• Fault tolerance is the ability to keep operating correctly when parts of the system fail, through redundancy, error handling, retries and self-healing. A fault-tolerant system has no single point of failure and detects and repairs faults automatically, without people stepping in. Taken literally, that would mean 100% availability, which isn't realistic.

Fault tolerance is one of the main ways to achieve high availability: if the system keeps working when components fail, failures don't become downtime. In interviews the two are treated as nearly the same thing; when an interviewer asks about fault tolerance, they usually mean availability.

Availability vs consistency

During a network partition, a replicated system must choose between staying available (answering, possibly with stale data) and staying consistent (refusing until it can be sure). That choice is the CAP theorem, and it is a product decision as much as a technical one: a shopping cart should accept writes, a bank transfer should not.