Foundations · lesson 1 of 5 · about 25 min
A repeatable template for any open-ended design question: how to spend 45 minutes, which questions change the design, how to estimate out loud, how to grow a sketch from a baseline, how to state trade-offs with numbers, and what goes wrong when you skip a question. Tap any for a plain-language card.
The shape of the hour
Each step has diminishing returns: the first three minutes of requirements are worth far more than minutes ten to fifteen. The model here is illustrative (an invented curve, coverage = 1 − e^(−minutes ÷ τ), with a weight per step), but its lesson is real: starving an early step makes everything after it guesswork, and one rabbit hole can eat the whole deep-dive.
Spend 20 minutes on one deep dive with 2 on requirements, and watch the total fall even though the dive is brilliant.
Coverage 75%. The thinnest area is "Requirements and scope" at 71%. Ask about users, scale, read/write mix, latency, consistency and what is out of scope.
Illustrative model: the shape (fast early gains, flat later) is realistic; the exact time constants and weights are invented for this exercise.
Clarify first
Below, each answer is converted into a consequence by arithmetic from earlier lessons: peak requests per second, the downtime budget, how many 99.5% servers you need to meet the target, and the speed-of-light cost of strong consistency across regions. Notice when two answers conflict: asking for strongly consistent writes across continents and a 100 ms p99 is impossible, and noticing that is the kind of insight interviewers hope to see.
Set strong consistency, 3 regions and a 100 ms p99, and watch the conflict appear.
Consistent set. About 3.47K requests a second at peak (316 writes), a downtime budget of 8 h 46 min a year, which needs 2 copies of a 99.5% component.
Arithmetic from your answers. Region round-trip times (80 and 150 ms) are illustrative round numbers; availability per node is an assumed 99.5%.
Estimate under pressure
Each problem below is generated from a seed. Work out the peak requests per second on paper, type it, and the page compares it with the exact answer on a log scale, which is how far off you are in orders of magnitude.
Try to do it in 60 seconds. Divide by 105, not by 86,400, and see how close you land.
A service has 32.2M daily users. Each makes 2 requests a day. Traffic at peak is 5× the average. What is the peak requests per second?
Enter an estimate and press Check.
The exact answer is computed from the seeded problem: users × requests ÷ 86,400 × peak.
High-level design
Toggle components to add them. The checker computes the design's availability by combining the parts in series and in parallel (with illustrative per-part availabilities of 99.9% for a balancer and 99.5% for a server, database or data centre), and compares the load at your peak with what one database (5,000 queries/s, illustrative) and the app servers (2,000/s each) can take.
Start empty at 6,000 requests a second. Which two additions fix the database first?
Single points of failure left: one load balancer, one app server, one database, one data centre. The database would see 6K queries a second against 5K it can do: add a cache (reads) or shard. The app tier takes 6K/s against 2K: add servers or move static files to a CDN.
A checklist model, not a benchmark: it shows the reasoning (find the failing number, add the box that fixes it), using round illustrative capacities.
Trade-offs
The staleness chance is exact (a combinatorial count of read sets that miss every write replica). Latencies are simulated: each replica answers in about 5 ms, with a 2% chance of being 15× slower. Try the common settings: (3, 1, 3) fast reads, slow writes; (3, 2, 2) balanced; (3, 1, 1) fastest and weakest.
Compare (N=5, R=1, W=1) with (5, 3, 3): the second never reads stale, and you can see what it costs at p99.
R + W = 4 is not above N = 5, so a read can land entirely on replicas that missed the latest write: 30.0% of reads are stale. In exchange reads (p99 6.9 ms) and writes (p99 7.0 ms) wait for fewer replicas.
Staleness: C(N−W, R) ÷ C(N, R), exact for random read sets. Latency: 4,000 seeded trials per setting.
What do you do next?
Knowing the template is not enough: you need to know which step you are in. Read the moment and choose the next step. Each answer is worth 20 XP.
Ask: what do I still not know? If the answer is the problem, clarify. If it is the numbers, estimate.
The interviewer has just said: "Design a ride-sharing service." You have heard nothing else.
Tip: press 1 to 4 to answer, Enter for the next one.
Who lives by this
Four published sources for structuring a design conversation.
understand → high-level design → deep dive → wrap up
Alex Xu's widely read book teaches a four-step process: understand the problem and set the scope, propose a high-level design and get buy-in, design in depth, and wrap up. It advises asking questions and writing down assumptions before designing, and treating the interviewer as a collaborator.
reliability · scalability · maintainability
Martin Kleppmann's book frames system design around three concerns, reliability, scalability and maintainability, and shows how to describe load with concrete parameters (requests per second, read to write ratio) and performance with percentiles rather than averages. It is the vocabulary most interviewers expect.
operational excellence · security · reliability · performance · cost · sustainability
AWS publishes a Well-Architected Framework that asks design questions under six pillars: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. It works as a checklist for the final trade-offs step: have you thought about each one for this design?
latency · traffic · errors · saturation
Google's SRE book names four golden signals to monitor for any user-facing system: latency, traffic, errors and saturation. Naming them when asked "how would you know it is working?" is a compact, credible answer for the wrap-up of a design.
Interview angle
Six questions, each worth 20 XP, about the interview itself.
Think aloud, keep the numbers rounded, and always say what you gave up.
Why ask clarifying questions before drawing anything?
Tip: press 1 to 3 to answer, Enter for the next one.
Break it
Set the ratio you designed for and the ratio the real world delivers, and optionally a traffic multiplier (the product was more popular than expected). The numbers show database load against the capacity you sized. The lesson for the interview is cheap: ask, or say the assumption aloud so the interviewer can correct it in the first five minutes instead of the last five.
Design for 20 : 1, then set the real ratio to 1 : 1 and traffic to 1.5×. Same boxes, a different system.
Reality needs 571/s against 3K capacity (19%): within limits, 1.0× the plan. Push the real ratio down or the traffic up to break it.
Base traffic 4,000 requests a second, 90% cache hit on reads, database capacity 3,000 a second (all illustrative). Writes always miss the cache.