Availability

Why it matters

Users do not care about your architecture; they care whether the page loads. Availability is the number that captures that, and it is the one most contracts are written around. It also has a property that surprises people the first time: it is multiplicative. Chain five components that are each up 99.9 percent of the time and the system is up about 99.5 percent, which is more than four times the downtime. Designing for availability is mostly about understanding that arithmetic.

The idea

Availability is the proportion of time a system is able to serve correct responses, usually quoted per year as a count of nines.

Availability	Downtime per year	Per month	What it takes
99 percent (two nines)	3.65 days	7.3 hours	A single well-run server, manual restarts
99.9 percent (three nines)	8.8 hours	44 minutes	Redundant servers, automated failover, monitoring
99.99 percent (four nines)	52 minutes	4.4 minutes	Multi-zone, no manual steps in recovery, careful deploys
99.999 percent (five nines)	5.3 minutes	26 seconds	Multi-region active-active; most products do not need it

Two related terms: an SLA is the availability you promise a customer, with penalties; an SLO is the tighter internal target you run against so you never breach the SLA. Error budgets fall out of the SLO: at 99.9 percent you may be down 44 minutes a month, and spending that budget on a risky deploy is a legitimate choice.

Series multiply, parallel multiply the other way

Components a request must pass through are in series: the availabilities multiply, so the chain is weaker than its weakest link. Components that can substitute for one another are in parallel: their unavailabilities multiply, so two 99 percent servers behind a balancer give about 99.99 percent, as long as the balancer itself is not the new weak link.

What actually raises availability

Redundancy, with automation. A spare that needs a human to switch to buys little at three nines and nothing at four. The checklist is short: no single point of failure, health checks that detect failure quickly, failover that happens without a person, and deploys that can be rolled back faster than the error budget burns.

Trade-offs

Every nine costs. Redundant infrastructure doubles spend, multi-region adds data-consistency problems, and the operational discipline to stay at four nines is a staffing decision as much as a technical one. Most products are well served by three nines for the core path and lower for everything else; stating that explicitly is a mark of judgement, not of ambition lacking.

Availability also trades against consistency when partitions happen, which is the CAP lesson at the end of this module.

In an interview

Pick a target and defend it: "Checkout should be at three nines or better; the recommendations widget can be two, because the page still renders without it." Then show the arithmetic: name the series chain, point at the weakest link, and say which parts you make redundant and how failover is automated. Mentioning error budgets signals you have operated a system, not just drawn one.