Availability, SLAs and SLOs

1The core idea#

Availability is the fraction of time your system is actually doing its job. Nothing more exotic than that.

• Answered requests correctly for 99 of every 100 minutes? You were 99% available.
• The formula people recite is uptime over total time.

availability = uptime / (uptime + downtime)

That formula is fine for a lightbulb. For a real service, measure from the user's side.

• Count the percentage of requests that succeeded, within a sane latency, over a window.
• A server that is "up" but returning 500s or taking 30 seconds is not available to the person waiting.
• "Good requests over total requests" is almost always the more honest number.

A concrete version. Say a checkout service handled 10,000,000 requests over 30 days.

• 9,994,000 returned a 2xx under 300ms.
• 6,000 either errored or blew past the latency bar.
• Your SLI is 9,994,000 / 10,000,000 = 99.94%.
• That single percentage is the thing everything else in this guide hangs off.

Now the vocabulary, because interviewers want you to use it correctly.

• SLI (Service Level Indicator): the actual measured number. "99.94% of requests in the last 30 days returned a 2xx under 300ms." This is reality.
• SLO (Service Level Objective): the target you set for the SLI. "We aim for 99.9% success." A goal your team owns, internal.
• SLA (Service Level Agreement): a promise to a customer, usually with money attached. "Drop below 99.5% this month and you get a 10% credit." A contract.

The nines, and what they actually cost#

"Three nines" means 99.9%. This is the table worth memorizing, because it shows up constantly.

Read that table twice. What it is really telling you:

• Three nines to four nines shrinks your whole-year downtime budget to under an hour.
• One bad deploy at 2am plus one slow rollback spends the entire annual budget in a single incident.
• Five nines (5.26 minutes a year) is a different universe: you cannot get there with humans in the recovery loop.
• A person paged at 2am needs 5 to 10 minutes just to open a laptop, so everything has to fail over automatically before anyone wakes up.

2How it works#

Availability is not one dial you turn. It comes from stacking a few techniques so no single component failing takes the whole system down.

The main levers.

• Redundancy. Run more than one of everything. Two app servers instead of one, so losing a box does not lose the service.
• Load balancing with health checks. Something in front that stops sending traffic to a sick instance.
• Failover. A standby that takes over when the primary dies, ideally without a human.
• Isolation. Blast radius control. One region or one shard going bad should not drag the rest down.

A simple resilient setup:

The point candidates miss: availability multiplies down a dependency chain.

• A request needs the service AND the database AND an auth component.
• Each is independently 99.9% available.
• Combined: 0.999 x 0.999 x 0.999 = 0.997, about 99.7%.
• You just lost a nine by adding two dependencies.
• Every hard dependency you add drags the number down. This is why people make dependencies optional (serve stale cache if the DB is slow) or add redundancy at each layer.

Redundancy pushes the other way.

• Two instances, each failing 0.1% of the time, where you only need one up.
• Both fail together only about 0.001 x 0.001 = 0.000001, roughly 0.0001% of the time.
• On paper that is three nines to six nines.
• The whole game in one line: serial dependencies hurt you, parallel redundancy helps you.

Error budgets#

This is the idea that ties SLOs to real decisions, and it is what separates a good answer from a great one.

• SLO of 99.9% explicitly allows 0.1% downtime.
• Over 30 days that is about 43 minutes.
• That 43 minutes is your error budget, a budget you are allowed to spend.

Make it concrete.

• By day 20 of the month, a bad migration has eaten 38 of those 43 minutes.
• You have 5 minutes left.
• That number alone tells the team what to do: no risky deploys until the window resets.

Why it matters: it turns a vague argument into math.

• "Ship the risky feature or stabilize?" stops being a vibe fight.
• Budget left over: ship, take the risk, push faster.
• Budget already blown this month: freeze risky deploys, spend the time on reliability.
• Product and engineering now share one number instead of arguing.

3A worked example: sizing a checkout service#

Put the whole thing together on one problem, because this is the level of specifics that scores in a loop.

• An online store doing $50M a year, roughly $5,700 of revenue per hour on average.
• Peaking around 4x that on sale days.
• Question to answer: what availability target, and what does it buy?

First, what does an outage cost?

• At $5,700 an hour, every minute of downtime at normal traffic is about $95 of lost orders, 4x that at peak.
• A single 43-minute outage at peak costs roughly 43 x 95 x 4 = about $16,000.
• Plus a chunk of customers who try once, hit an error, and never come back. That second cost is the one that keeps you up at night.

Now price the targets against the nines table.

• 99.9% (three nines, 43 min/month): single region, one hot standby app instance behind a load balancer, primary DB with a read replica for failover. Cheap. Roughly one extra app box and one replica.
• 99.95% (22 min/month): same shape, plus automated DB failover and a tighter deploy process (canary, fast rollback). Modest extra spend, mostly engineering time.
• 99.99% (four nines, 4.32 min/month): second region active-active, cross-region data replication, failover that runs without a human. The infra bill roughly doubles because half of it sits idle waiting for a failure, and you take on split brain.

The one sentence to say out loud.

• 99.9% to 99.95% halves downtime for mostly engineering time.
• 99.95% to 99.99% costs a doubled infra bill for a few thousand dollars saved.
• The marginal dollar stops being worth it right around the fourth nine for this service.

4Trade-offs#

Every extra nine costs real money and real complexity, and the cost is not linear.

• 99% to 99.9% might mean one replica and a health check.
• 99.9% to 99.99% might mean multi-region, automated failover, and a team to keep it working.

The trade-off interviewers love: availability versus consistency, straight out of CAP.

• A network partition forces a pick: stay available and risk stale or conflicting data, or stay consistent and refuse to serve.
• A shopping cart leans available (keep adding items, reconcile later).
• A bank transfer leans consistent (better to reject than double-spend).
• Say which one your design picks and why.

The other real trade-off: cost versus marginal benefit.

• Internal dashboard used nine-to-five: three nines is plenty, chasing four is money on fire.
• Payments API: those extra minutes are lost revenue and lost trust, so the spend is justified.
• The right answer is always "it depends what this system does," and a good candidate says so, then actually picks a number.

Let the cost of downtime pick the target, not the urge to say "highly available."

5Where it is used#

Every serious production system sets availability targets, but the number varies wildly by what is at stake.

• Public cloud services publish SLAs you can look up. A managed database or compute SLA around 99.9% to 99.99% is typical, with service credits if they miss. Notice they promise money back, not that it will never break.
• Payment and checkout flows push hard for four nines and up, because every minute down is lost sales and a customer who may not return.
• Streaming and social feeds favor availability over strict correctness. Recommendation engine down? Show something cached and slightly stale rather than an error. Nobody files a complaint because their feed was five minutes old.
• Internal tools often sit at two or three nines on purpose. More is not worth it when the users are your own employees.

When to reach for the toolkit, and when to hold back.

• Reach for redundancy, failover, and isolation the moment downtime has a real cost: money, safety, or reputation.
• Hold back deliberately when the system is cheap to retry or nobody is hurt by a short outage.

6Common pitfalls and gotchas#

Promising an SLA tighter than your SLO.

• Commit to customers at 99.99% while targeting 99.9% internally and you have no buffer.
• The internal goal must be stricter than the external promise. Always.

Measuring uptime instead of user success.

• "The servers were up" is not "users got answers."
• A load balancer routing happily to instances returning 500s shows green on a naive uptime check while every customer fails.
• Measure from the user's perspective: good requests over total requests.

Forgetting dependencies drag you down.

• A candidate proudly designs a 99.99% service that calls a 99% third-party API on every request.
• Real availability is now capped near 99%. Three nines of work thrown away.
• You cannot be more available than the weakest thing you hard-depend on, unless you make it optional or add a fallback.

Counting planned maintenance as free.

• Downtime is downtime. Take the service offline to upgrade and that comes out of your budget too.
• Exception: your SLA explicitly carves out maintenance windows, and customers increasingly refuse that clause.

Chasing nines nobody asked for.

• The most expensive mistake is over-engineering.
• Five nines on a feature that could tolerate an hour of downtime is wasted money and needless complexity.
• Match the target to the business need.

Averaging over too long a window.

• "99.9% over the year" can hide a brutal six-hour outage if the rest of the year was perfect.
• Six hours is 360 minutes, well past a three-nines yearly budget of 8.76 hours all on its own, yet a yearly average smooths it into looking fine.
• Measure over a rolling 30-day window so a single bad incident shows up and forces a response.

7How it shows up in interviews#

Interviewers probe availability to see if you can reason about failure instead of drawing happy paths. Here is what they listen for, weak and strong side by side.

"What is your availability target?"

• Weak: "It should be highly available." No number, nothing to defend. I learn nothing.
• Strong: "For this checkout service I would target 99.95%, about 22 minutes a month. Being down costs roughly $95 a minute in lost sales, so a hot standby and automated DB failover pay for themselves. For the admin dashboard in the same system I would settle for 99.9% and skip the extra redundancy, because the only users are our own staff."

"What happens when the primary database fails?"

• Weak: "It fails over to the backup." Hand-wave. No mechanism, no blip, no data story.
• Strong: "Health checks mark the primary dead after two missed checks, the replica is promoted, there is a few-second blip while connections re-point, and writes in flight at the moment of failure may need a client retry. If a whole region goes dark, traffic shifts to the second region via DNS or a global load balancer within a minute or two." Naming the specific failure and the specific recovery is what scores.

The consistency trade-off.

• Weak: "It will always be consistent and always available." Now I know you have not understood CAP, because under a partition you cannot have both.
• Strong: "During a partition I favor availability here and reconcile conflicts afterward, because a stale product listing beats an error page. For the payment write path I flip it and favor consistency, because a double charge is worse than a rejected request."

Error budgets, which you bring up unprompted.

• Weak: never mentions them.
• Strong: "I would set a 99.9% SLO, which gives a 43-minute monthly error budget, and freeze risky deploys once we burn it." That one sentence says you have operated real systems, not just read about them.

The thread running through all of it: put numbers on things, know what each nine costs, and be willing to say "this level of availability is not worth it here."

Next, try the System Design Question walkthrough on designing a URL shortener, where you will set concrete availability targets for the read and write paths and defend them.