Availability

Availability is the percentage of time a system is able to successfully respond to requests. If a service is "available," it doesn't mean it's fast or correct — only that it's up and answering. It's usually expressed as a percentage of uptime over a year, using a shorthand people call "the nines":

Availability	Downtime per year	Downtime per month
99% ("two nines")	~3.65 days	~7.3 hours
99.9% ("three nines")	~8.76 hours	~43.8 minutes
99.99% ("four nines")	~52.6 minutes	~4.4 minutes
99.999% ("five nines")	~5.26 minutes	~26 seconds

The jump between each tier is dramatic. Going from 99.9% to 99.99% means finding and eliminating almost an entire order of magnitude of failure time — which typically requires structurally different engineering (removing single points of failure, automating failover, catching partial degradations before they cascade), not just "trying harder."

System Design Lab

Server B failing doesn't show up as downtime to the user at all — the load balancer already routed around it.

Availability is a design target, not an accident

In an interview, availability is one of the first things worth clarifying with the interviewer, because it drives real architectural decisions: a system that's allowed 8 hours of downtime a year can get away with a single database and manual failover; a system that needs 5-nines cannot have any single component whose failure takes the whole system down. That's the direct link to Single Point of Failure — every SPOF you leave in a design puts a ceiling on the availability you can claim.

The standard techniques for raising availability all boil down to removing dependence on any one thing being up:

• Redundancy — run multiple instances of every critical component (servers, databases, even entire data centers), so one failing doesn't take down the service.
• Failover — detect a failed instance and automatically shift traffic to a healthy one (see the Failover lesson).
• Load balancing — spread traffic across redundant instances so no single one is a bottleneck or a hidden SPOF.
• Graceful degradation — when a non-critical dependency is down, keep serving a reduced experience instead of failing the whole request (e.g., a product page that shows without personalized recommendations if the recommendation service is unreachable).

Availability vs. reliability

These two terms get used almost interchangeably in casual conversation, but they answer different questions, and interviewers do notice the difference:

• Availability asks: is the system responding right now?
• Reliability asks: does the system keep working correctly over time, without failures? (covered in the next lesson, Reliability)

A system can be highly available but not very reliable — for example, a server that's always up but returns wrong data 1% of the time due to a race condition is "available" the whole time, but not reliable. Conversely, a system that's extremely reliable when it's up, but that goes through frequent short outages, is reliable-but-not-available. Good system design usually needs both, but they're improved with different techniques, so it's worth naming which one a given design decision is actually targeting.

The SLA / SLO / SLI vocabulary

You'll often hear availability discussed alongside three related terms, borrowed from Google's SRE practice:

• SLI (Service Level Indicator) — the actual measured metric, e.g. "percentage of requests that succeeded in the last 28 days."
• SLO (Service Level Objective) — the internal target for that metric, e.g. "99.9% of requests succeed."
• SLA (Service Level Agreement) — an external, often contractual, commitment to customers, usually with a stated SLO and a penalty if it's missed.

Being able to use these three terms precisely is a small but real signal of experience in an interview.

Chasing another nine: pros and cons

Pros

• ✓Fewer user-facing outages and support tickets
• ✓Fewer 3am pages — failures get routed around automatically
• ✓Higher trust from users and from downstream teams depending on you

Cons

• ✕Cost and engineering effort grow roughly exponentially per extra nine
• ✕More redundant infrastructure to build, monitor, and pay for
• ✕Diminishing returns — most products don't need 5-nines and it can be wasted effort

Further Reading

• Google SRE Book — Service Level Objectives — the primary source for the SLI/SLO/SLA vocabulary and how Google reasons about availability targets.
• Wikipedia — High availability — a concise reference for the "nines" table and standard availability techniques.