Question presented to candidate:
"Our checkout service needs to be highly available. Walk me through how you would design it, how you would measure availability, and where the downtime actually comes from."
What a strong answer should cover:
A measurable target: availability as a fraction of successful requests or time, the nines and the downtime error budget each one allows (99.9% is about 8.8 hours a year, 99.99% about 53 minutes)
The arithmetic: components in series multiply (the chain is worse than its weakest part); redundant copies in parallel raise availability only if their failures are independent
Removing single points of failure across every tier, spreading copies across failure domains (availability zones, regions), and sizing N+1 capacity so the survivors are not overloaded
Failover is part of the design: detection time (health check interval times threshold), DNS TTL and promotion time are downtime on every failure
Keeping failures small: timeouts, retries with backoff, circuit breakers, load shedding, graceful degradation, and safe deployments, which cause a large share of real outages
Clarifying questions expected:
What availability target, measured how (successful requests, or minutes the service was up), and what does one minute of downtime cost?
Which parts must stay up (take payment) and which can degrade (recommendations)?
One region or several, and what data consistency does checkout need during a failover?
Code / implementation expected: Optional โ availability arithmetic for a real topology; the example computes serial and parallel availability, failover cost, correlated zone failure and N+1 sizing.
availability
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Beginners to reliability engineering โ you know what a server, a load balancer and a database are; every reliability term is defined as we go.
Difficulty: Medium
Verified with: Node 22.22 and Python 3.12 (both print identical output). All component availabilities in the run are stated assumptions, not vendor SLAs; AWS health-check defaults are from the Amazon Route 53 Developer Guide, checked in October 2026.
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the exact words an interviewer expects. All numbers in the tables come from the example program; the Verified section quotes its full output.
1. Why This Even Matters โ A Story First
A wedding has one photographer, one caterer, one DJ and one venue. Each is very reliable: say each turns up 999 times out of 1,000.
The solution is hidden so you can try first
15 min read ยท 14 sections
4
Read the code
Availability arithmetic: serial chains, redundancy, failover time, correlated zone failure and N+1 capacity