Availability System Design Interview: A Spoken Framework

When an interviewer asks about availability in an availability system design interview, they are not testing whether you can recite a nines table. They want to hear you define availability for the user and the operation, name the failures you are designing against, pick a target with a reason, and say what that target costs. The candidate who says "available for whom, doing what, during which failure?" and then defends a trade-off sounds senior. The candidate who quotes nines sounds like they read a table.

What does the interviewer actually want when they ask about availability?

They want to hear your reasoning, not your memory. Three things are usually being scored:

Can you name failure modes? A single node dying, a zone going away, a dependency timing out, a bad deploy, corrupted data. Each one changes the design.
Can you pick a target with a reason? A number tied to the product, not to habit or a competitor's marketing page.
Can you defend what you gave up? Every availability target costs consistency, money, latency or operational complexity. Naming the cost shows you thought it through.

A one-sentence definition you can say out loud: availability is the fraction of requests that succeed within an acceptable latency, for a defined class of users, during a defined set of failures. That sentence has four moving parts, and you can adjust each one for the system in front of you.

A bare percentage is a weak answer because it is a number with no system attached. It does not say which requests, which users, which failures, or what you paid to get there. The interviewer cannot tell whether you understand the number or just remembered it.

The four-beat spoken framework: Define, Fail, Target, Trade

Use this order every time. It gives your answer a shape the interviewer can follow, and it keeps you from drifting into a component list.

Define. Say which operation and which users you are talking about. Reads versus writes, checkout versus browse, logged-in versus anonymous. Availability is not one property of a whole system.
Fail. List the failure modes you are designing against. Single node, single zone, a dependency, a deploy, data corruption. Name the ones you are covering and the ones you are not.
Target. State a number and justify it from the product. Why does this operation need that level, and what happens to the user when it is down?
Trade. Name what the target costs you: consistency, money, latency or operational complexity. One sentence is enough if it is specific.

Rehearse the checklist until the four beats come out in order without notes. The content changes per system; the shape does not.

Worked example: a 90-second availability answer for a ticket-booking system

Here is a full answer as you would say it, for a system that lets people browse events, pick seats and pay. Read it aloud once to feel the rhythm.

"I'll split availability by operation, because the three flows have different stakes. For browsing events, availability means the listing and event pages return within a couple of hundred milliseconds for any user, even if one zone is down. I'd design against a single node failure and a single zone failure, and I'd accept slightly stale data — a seat count that is a few seconds old is fine for browsing. For seat selection, availability means a user can see and hold a seat without double-booking it. That needs stronger coordination, so I'd plan for a node going down and a dependency timing out, and I'd rather return a clear 'seat no longer available' than risk two people holding the same seat. For payment, availability means the charge either succeeds or fails cleanly, never twice. I'd target a slightly lower availability on payment than on browse, because a wrong confirmation is worse than a retry. The trade is that payment is more expensive and more complex to operate, and I accept that because the cost of a double charge to the user is higher than the cost of a retry."

What each beat is doing:

Define: the answer opens by splitting browse, seat selection and payment. That single move signals you know availability is per operation.
Fail: each flow names its failure modes — zone loss for browse, dependency timeout for seat selection, duplicate charge for payment.
Target: the numbers are relative and reasoned ("a couple of hundred milliseconds", "slightly lower on payment") rather than recited.
Trade: the final sentence states the cost explicitly and why you accept it. That is the sentence interviewers remember.

Copy the structure, not the words. The same four beats work for a chat system, a feed or a payments API.

How do you pick an availability target without inventing numbers?

Derive the target from the cost of downtime to the user, not from a competitor's marketing page. Ask what actually happens when this operation is down for a minute: does the user wait, retry, or leave and not come back? A browse outage is annoying; a payment outage that loses a confirmed order is worse.

Treat the target as a budget you spend. An availability target is what you have left after deploys, experiments and maintenance. If you deploy often, some of that budget goes to deploys, and you plan rollbacks and canaries accordingly. Saying this shows you understand availability as an operating practice, not a badge.

When you do not know the business context, say so honestly and move on:

"I don't know the revenue impact here, so I'd start at a target that's easy to reason about — say, three nines for browse and a bit lower for payment — and revisit it once we know what an outage actually costs. The important part is that the target is written down and the failure modes are covered."

That script keeps you calm and keeps the thread. Admitting uncertainty about the business is fine; drifting without a target is not.

Which trade-offs will the interviewer push on?

Expect at least one push-back after your first answer. Have a one-line reply ready for each of these.

Availability versus consistency. The classic push-back. Choose per operation: "For seat holds I'll take consistency over availability, because a double-booked seat is a worse user experience than a retry." Our guide to consistency models goes deeper on picking and defending that choice.
Availability versus cost. Redundancy, multi-zone and multi-region all cost money. Say when it is too much: "Multi-region is more than this feature needs; a single region with multi-zone failover covers the failure modes I named."
Availability versus latency. Retries, timeouts and fallbacks are availability tools that also add latency. "I'd add a short timeout and a fallback to a cached response, and accept the extra few milliseconds because a fast failure beats a hang."
Availability versus complexity. Sometimes the simpler design is the honest answer: "A single-region design with a clear runbook is more reliable for this team than a multi-region setup we can't operate well."

Each of these is a sentence you can reuse. The pattern is the same: name the tension, pick a side, give the reason.

Weak answer vs stronger answer: a before-and-after rewrite

Here is a typical weak answer and the same idea rebuilt through the four beats.

Weak: "We need high availability, so we use multiple replicas and a load balancer."

Stronger: "For reads, availability means the feed loads for any user even if one node dies. I'd design against single-node and single-zone failure with replicas across zones behind a load balancer. I'd target three nines for reads and accept slightly stale content, because a feed that's a few seconds behind is fine. The trade is extra cost and a bit more operational work to keep replicas in sync."

What changed: the weak answer names components; the stronger one names failures, a target and a cost. The interviewer can now ask a real follow-up instead of guessing what you meant.

The pattern repeats on follow-ups. If they ask "what about writes?", run the four beats again briefly: "For writes, availability means the post is accepted and eventually visible. I'd plan for a node going down and accept eventual consistency, targeting a slightly lower number than reads because a delayed post is acceptable." For more on handling that second layer of questions, see responding to follow-up questions.

The three mistakes that sink availability answers

Reciting nines without connecting them to a user or an operation. Correction: "For this operation, availability means the user can complete the action; here's the target and why."
Listing redundancy as if it were availability, without naming the failure it covers. Correction: "Replicas across zones cover a single-zone failure; here's what they don't cover."
Never naming what you gave up. Correction: "The cost of this target is more money and more operational complexity, and I accept that because..."

Each correction is one sentence. Practise saying them until they come out without a pause.

How to practise this out loud before the interview

Fifteen minutes is enough for one round. Do this:

Pick a system you know well — a booking flow, a feed, a chat app.
Run the four beats aloud, timing yourself to about 90 seconds.
Record yourself and listen for a missing trade-off or a number with no reason.
Have someone push on consistency and cost after your first answer, or rehearse the follow-up layer yourself.
Rehearse the uncertainty script so "I would start at X and revisit" sounds calm rather than evasive.

For the next session, read up on the related fundamentals: API design in a system design interview and non-functional requirements in a system design interview use the same defend-your-number habit.

Before you walk in

Availability answers are won by structure, not by memorised percentages. Say the four beats in order — define, fail, target, trade — and finish with the cost you accepted. Pick one system you know, run the framework aloud once tonight, and listen for the trade-off sentence. If it is missing, that is the one thing to fix before the interview.

Frequently asked questions

Do I need to memorise the nines table for an availability system design interview?

No. Knowing roughly what the common nines mean in downtime is useful context, but the interviewer is scoring your reasoning, not recall. A candidate who says "three nines for browse, lower for payment, because a wrong confirmation is worse than a retry" is stronger than one who recites a table without tying it to an operation.

What if the interviewer gives me an availability target — how do I design backwards from it?

Treat the target as a budget and spend it on failures. First ask which operation and users it covers, then list the failure modes that would breach it, then choose redundancy, retries or fallbacks for each. Finish by naming what the target forces you to give up, such as consistency or cost, so the interviewer sees you can work from a constraint rather than only propose one.

How do I talk about availability when I have never operated a production system?

Reason from the user and the failure, not from experience. Say what happens to a user when the operation is down, name the failure modes you would design against, and state a target with a reason. You can add that you would validate the target with the team once you know real outage costs, which is honest and still shows structured thinking.

Is multi-region always the right answer for high availability?

No. Multi-region covers region-level failures but adds cost, latency and operational complexity. If your failure list only includes single-node and single-zone failures, a single region with multi-zone failover is the more honest design. Say which failures multi-region covers and which it does not, and name the cost you would accept to get it.

How does availability differ from reliability and fault tolerance in an interview answer?

Availability is the fraction of requests that succeed within an acceptable latency for defined users during defined failures. Reliability is the broader promise that the system behaves correctly over time, including data integrity. Fault tolerance is a design property — the ability to keep working when part of the system fails. In an answer, use availability for the target, reliability for correctness, and fault tolerance for the mechanisms.

Practise your availability answer aloud and review the trade-off sentence.