Availability and "The Nines" Explained

Availability, reliability and durability

These three words are often mixed up. Here is what each one means:

• Availability: can I use it right now? (Is the site up?)
• Reliability: does it work correctly, over time? (Does it give the right answers, even when parts fail?)
• Durability: is my data safe? (Will my saved file still exist next year?) Data that stays saved and is not lost is called durable.

A system can be available but not reliable: it is up, but it shows wrong prices. It can also be durable but not available: your photos are safe in storage, but the app is down so you cannot see them.

The nines table

Look at five nines: 26 seconds a month. This is often less time than a person needs to notice an alert, open a laptop and log in. At that level, recovery must be automatic.

Two ways to measure it

Time-based availability asks what fraction of time the system was up:

Availability = uptime / (uptime + downtime)

Request-based availability asks what fraction of requests succeeded:

Availability = successful requests / total requests

Request-based is usually more useful for web services:

• If your site is "up" but 10% of checkout requests fail, the time-based number says 100%, but users would not agree.
• An outage at 3 AM, when few people use the site, hurts fewer users than an outage at 8 PM.

MTBF and MTTR

Two numbers describe how often things break and how fast you fix them. "Mean" means average:

• MTBF (Mean Time Between Failures): the average time between one failure and the next.
• MTTR (Mean Time To Recovery): the average time it takes to recover after a failure.

Availability = MTBF / (MTBF + MTTR)

Example: your service fails about once a month (MTBF ≈ 720 hours).

• If recovery takes 4 hours: 720 / 724 ≈ 99.45%.
• If recovery takes 15 minutes: 720 / 720.25 ≈ 99.97%.

The failure rate did not change, but availability improved a lot. You can reduce recovery time with good monitoring (watching the system and raising alerts), quick rollbacks (going back to the previous working version) and automatic failover. This is often easier and cheaper than preventing every failure.

Composite availability: series

Your system is a chain of components. If a request needs all of them to work (this is called "in series"), their availabilities multiply:

The whole is less available than its weakest part. Every extra dependency (something your system needs in order to work) in the request path lowers the total availability. Three services each at 99.9% in a chain give about 99.7%. That is about 26 hours of downtime a year, instead of about 9.

This is why:

• You cannot promise 99.99% if your system depends on a third-party API (a service run by another company) that offers only 99.9%, unless you have a fallback (a backup plan, such as a saved answer).
• Fewer hard dependencies in the critical path (the steps every request must pass) means better availability.

Composite availability: parallel (redundancy)

Redundancy means keeping extra copies of a component. If you have two copies and only need one to work (this is called "in parallel"), availability goes up:

Total = 1 − (chance both fail at the same time)      = 1 − (1 − A) × (1 − B)

Example: two servers, each 99% available:

Two "two nines" servers together give "four nines". This is the power of redundancy.

The big catch: this maths assumes the two copies fail independently (one failing does not make the other more likely to fail). In real life, failures are often correlated, which means they happen together:

• both servers are in the same data centre (a building full of servers), which loses power,
• both run the same release of the code, and it has a bug,
• both depend on the same database or DNS provider,
• the same bad configuration change is pushed to both.

This is why real systems spread copies across availability zones (separate data centres in one city area) and regions (separate geographic areas), and roll out changes slowly, a few servers at a time. More on this in Part 7.

Planned vs unplanned downtime

• Unplanned downtime: crashes, bugs, hardware failures, outages.
• Planned downtime: maintenance windows, which are set times for upgrades or migrations (moving data or systems).

Some services exclude planned maintenance from their availability numbers, and many banks announce "scheduled maintenance" at night. Modern systems aim for zero planned downtime. They use rolling deploys (updating servers one at a time) and online migrations (changes made while the system keeps running), so maintenance does not affect users.

SLAs: promises with consequences

An SLA (Service Level Agreement) is a written promise to customers, usually with money attached. For example: "If monthly availability drops below 99.9%, you get a 10% credit." Internal targets (called SLOs, Service Level Objectives, covered in Part 8) are usually stricter than the SLA, so you notice problems before you break your promise. Difference in one line: an SLA is the promise to customers, an SLO is your own goal.

How much availability do you need?

More nines are not always better. Each nine costs more:

Also ask: what do users actually notice? If a user's own Wi-Fi or mobile network is only about 99% reliable, spending millions to go from 99.99% to 99.999% may not change their experience much. Pick the target based on what downtime costs the business, not on "more is better".