Availability: Nines, SLAs, and Error Budgets

Why this matters: "highly available" is the most-used and least-defended phrase in system design interviews. Knowing what a nine costs — in architecture, in money, in on-call pain — is what turns it into an engineering decision.

Key takeaway

Availability is the percentage of time a service or infrastructure is accessible and functional under normal conditions. Each additional nine cuts your allowed downtime by 10x and typically multiplies your cost and complexity. The engineering question is never "can we be more available?" — it is "is the next nine worth what it costs?"

Measuring availability

The basic definition is a ratio of time:

Availability = Uptime / (Uptime + Downtime)

Expressed against MTBF and MTTR — the reliability metrics from the next lesson — the same quantity is:

Availability = MTBF / (MTBF + MTTR)

That second form is the more useful one, because it shows the two independent levers. You can raise availability by failing less often (higher MTBF) or by recovering faster (lower MTTR). Most teams over-invest in the first and under-invest in the second, even though cutting recovery time is usually far cheaper than preventing every failure.

The nines

Industry states availability in "nines." What each one actually permits:

Availability	Downtime per year	Downtime per month	What it implies
90% (one nine)	36.5 days	73 hours	Hobby project
99% (two nines)	3.65 days	7.3 hours	Internal tools
99.9% (three nines)	8.77 hours	43.8 minutes	Typical SaaS; humans can be paged and still make it
99.99% (four nines)	52.6 minutes	4.4 minutes	Recovery must be automated — no time to wake anyone
99.999% (five nines)	5.26 minutes	26 seconds	Redundancy everywhere; failover in seconds, unattended
99.9999% (six nines)	31.5 seconds	2.6 seconds	Telecom / safety-critical; extraordinary cost

Five nines — under six minutes of downtime a year — is the commonly cited gold standard and is genuinely hard to achieve.

Time-based is not the only definition

The formula above measures wall-clock uptime, but users don't experience wall clocks — they experience requests. Large services increasingly measure availability as a success rate:

Availability = Successful requests / Total requests

This is strictly better for two reasons. It captures partial failures — the gray-failure and omission cases from Chapter 1, where a node is "up" while dropping 30% of traffic — and it weights outages by how many users were actually affected. A ten-minute outage at 3 a.m. and one at peak hour are identical on a wall clock and wildly different to your customers.

How availability composes

This is the part candidates most often get wrong, and it has the biggest architectural consequences.

Dependencies in series multiply

If your request must traverse several components, and any one failing fails the request, availability multiplies:

A_total = A_1 * A_2 * ... * A_n

That chain gives 0.9999 * 0.999 * 0.999, about 99.79% — roughly 18 hours of downtime a year, worse than any individual component. Every synchronous dependency you add subtracts from your own availability, which is the availability math behind Chapter 1's warning about temporal coupling.

Redundant components in parallel

If a component is replicated and any one copy can serve the request, the failures must coincide, so unavailability multiplies instead:

A_total = 1 - (1 - A_single)^n

Setup	Per-component availability	Combined	Downtime per year
1 instance	99%	99%	3.65 days
2 instances	99%	99.99%	52.6 minutes
3 instances	99%	99.9999%	31.5 seconds

Two mediocre replicas beat one excellent server. This is the entire mathematical case for redundancy, and it is why horizontal redundancy is almost always cheaper than buying reliability in a single box.

Availability and service providers

Cloud and SaaS providers publish availability commitments, and the vocabulary is precise:

Term	What it is	Who it's for	Consequence of breach
SLI (indicator)	The measured number — e.g. request success rate	Engineers	None — it's a measurement
SLO (objective)	Your internal target — e.g. 99.95%	Your team	Engineering priority shifts to reliability
SLA (agreement)	The contractual promise to customers, always looser than the SLO	Customers, legal	Service credits, refunds, contractual penalty

Providers state these concretely: EC2 virtual machines carry a 99.95% uptime commitment, and storage services publish their own separate numbers. Note that a provider's SLA typically pays out in service credits — the refund is a fraction of your bill, not compensation for your lost revenue. Their SLA is a pricing mechanism, not an insurance policy.

Error budgets

The most useful idea in this lesson. If your SLO is 99.9%, you are permitted 0.1% unavailability — and that permission is a budget you get to spend:

Error budget = 1 - SLO
99.9% SLO  ->  0.1%  ->  ~43 minutes of downtime per month

This reframes reliability from a moral question into an engineering one:

Budget remaining? Ship faster. Take risks. Run experiments and deploy on Fridays. Unspent budget is wasted opportunity — an SLO you never miss means you over-invested in reliability and under-invested in features.
Budget exhausted? Feature work stops. Everything goes to reliability until the budget recovers.