Appearance
11.0 — The System Design Method
Forty-five minutes on the clock. The interviewer says "design Twitter" and then stops talking. There is no second prompt, no list of features, no numbers. What you do in the next five minutes decides most of the grade, and it is not drawing.
The mistake almost everyone makes is to start drawing. A box appears at minute three, a second box at minute four, an arrow between them at minute five, and by minute twenty there are twelve boxes on the board and not one number anywhere. The interviewer now has nothing to grade. They cannot tell whether the cache is there because you reasoned about a read/write ratio or because caches are what people draw. So they push on one box to find the bottom, you have not thought about that box, and the round ends politely.
This page is the method that stops that happening. It is a protocol you run every time, in the same order, in the same minutes, and every study in this Part is written in exactly this order so that reading them trains the protocol rather than just filling your head with architectures.
1. The first five minutes: turn a vague prompt into a scoped problem
"Design Twitter" is not a problem statement. It is an invitation to write one. Your first job is to convert it into three lists you say out loud and write in a corner of the board.
Functional requirements are the things a user can do. Pick three or four, not ten. For Twitter: post a tweet, follow a user, read a home timeline. That is a whole system and a full forty-five minutes.
Non-functional requirements are the numbers and promises the system must keep while doing those things. These are what actually shape the architecture: how many daily active users, what the read/write ratio looks like, what latency the user is allowed to feel, how stale a piece of data may be, and how available the system must stay. "Timeline loads in under 200 ms at the 99th percentile, and a tweet may take up to five seconds to appear in a follower's timeline" is a design brief. "It should be fast" is not.
Out of scope is the list you say you are not building today. Direct messages, search, ads, trending topics, media transcoding. Saying this aloud is not dodging work — it is the single clearest signal that you understand a system has more surface than one session can cover, and every interviewer grades it positively. The exact sentence to use: "I'm going to leave direct messages and search out of scope today and focus on posting, following and the home timeline — happy to come back to either if you'd rather see one of them."
The clarifying questions worth asking, and what each one changes
Do not ask questions to look thorough. Ask the ones whose answers change your architecture, and say why you are asking as you ask. Six questions cover almost every prompt:
"What is the read/write ratio?" This decides where your effort goes. A hundred reads per write means you build for reads and the write path can be simple and even slow. A one-to-one ratio, like a chat system, means the write path is the design. Everything downstream — caching, replication, whether you precompute anything — follows from this one number (10.2).
"What is allowed to be stale, and for how long?" This is the consistency question asked in a way a product person can answer. A follower count may be two minutes old and nobody is harmed. A bank balance may not. Getting a specific staleness budget lets you use caches and asynchronous pipelines with confidence instead of apologising for them (10.7.1).
"How many daily active users, and how spiky is the traffic?" Average load tells you almost nothing. The peak-to-average multiplier is what sizes the system. Social products run at roughly two to three times average at peak. A ticket sale runs at a thousand times average for ninety seconds, which is a completely different machine (11.16).
"Is this global or single-region?" One region means one database can be the source of truth and your life is simple. Multiple regions with writes in each means you have to answer what happens when two regions disagree, and that answer reshapes the data model, not just the deployment.
"What is the size of the largest single item?" A 280-character tweet, a 4 KB document and a 4 GB video produce three different systems with the same box diagram. Object size decides whether blobs live in the database or in object storage with only a pointer in the database.
"What happens if this is down for five minutes?" The answer separates systems where you may shed load and apologise from systems where you may not. It also tells you which parts genuinely need the reliability ladder and which are allowed to fail quietly (10.9).
Ask three or four of these, not all six. Then state the answers back as assumptions — "so: 300 million daily users, 100 reads per write, timelines may lag five seconds, single region for today" — and start the clock on estimation.
2. The 45-minute protocol
| Minutes | Phase | What must exist on the board when it ends |
|---|---|---|
| 0–5 | Requirements | 3–4 features, the numbers, the deferral list |
| 5–10 | Estimation | QPS, storage, bandwidth, and what each rules out |
| 10–15 | API + data model | endpoints, entities, partition key with a reason |
| 15–25 | Architecture | one clear request path through named components |
| 25–40 | Deep dives | 2–3 components taken three levels down |
| 40–45 | Scale & failure | 10× and 100×, the failure table, the ledger |
Two things about this clock are worth saying plainly. First, the phases are not equal in value: minutes 25 to 40 are where a senior candidate separates from a mid-level one, and every earlier phase exists to make those fifteen minutes possible. Second, you are allowed to go backwards. If your estimation produces 40 TB a day and you had assumed a relational store, say so and change the assumption out loud. Walking back a phase with a reason reads as engineering. Carrying a contradiction forward reads as not noticing.
3. Estimation that forces the architecture
Estimation is not a ritual where you produce a number and then design whatever you were going to design anyway. Every number you write must be followed by a sentence naming the choice it forces or eliminates. If a number changes nothing, do not compute it.
The five constants worth memorising
You cannot do this arithmetic live without a handful of numbers in your head. These five cover nearly everything:
| Quantity | Value to use | Where it shows up |
|---|---|---|
| Seconds per day | 86,400 (≈ 100k) | daily events to QPS |
| Seconds per month | 2.6 million | monthly volume to QPS |
| Peak multiplier | 2–3× average | sizing the fleet |
| One row of metadata | ~100 bytes–1 KB | storage per day |
| One text message | ~100 bytes | chat and feed storage |
Rounding 86,400 up to 100,000 is deliberate. It makes division mental — a million events a day is ten a second — and it errs on the safe side by understating QPS by about 15%, which you then swamp with the peak multiplier anyway. Nobody has ever failed an interview for using 100k seconds in a day; several have failed for spending ninety seconds on long division (10.12).
The three quantities to derive, in order
Requests per second. Take the user count, multiply by actions per user per day, divide by 100,000, then multiply by your peak factor. For Twitter: 300M daily users, each loading their timeline twice a day, is 600M reads a day, which is 6,000 reads a second average and roughly 15,000 at peak. What that forces: 15,000 reads a second is far past what one database serves comfortably, so the timeline must be served from something precomputed and cached, not assembled by query at read time. The number chose the architecture.
Storage per day, and then per year. Take the write rate, multiply by the size of one record, and be honest about the multipliers people forget: replication (usually 3×), indexes (often another 20–50% of table size), and retention (how long you keep it). For Twitter: 300M tweets a day at ~300 bytes of text and metadata is 90 GB a day, times three for replication is 270 GB a day, roughly 100 TB a year of text. What that forces: 100 TB a year is large but not exotic — it partitions across a modest cluster. What would have forced a different answer is media: attach one 2 MB image to 10% of tweets and you are at 60 TB a day, which pushes blobs out of the database into object storage immediately.
Bandwidth, when objects are big. Requests per second times bytes per response. For a video platform this is the whole design; for a text feed it is usually irrelevant and you should say so and move on. Knowing which numbers to skip is part of the skill.
The sanity checks that catch a wrong answer
Two habits catch most arithmetic errors before the interviewer does. First, check the order of magnitude against something you know: if your design needs 400,000 writes a second to a single relational database, that is wrong by roughly two orders of magnitude and you should notice without being told. Second, state units on every number and carry them through the multiplication. Most estimation mistakes in interviews are not arithmetic errors, they are unit errors — bits confused with bytes, per-day confused with per-second, or a monthly figure quietly compared against a daily one.
4. The API sketch: small, complete, and honest about the hard parts
Ten to fifteen minutes buys a handful of endpoints, not a specification. Write four or five, with the request body, the success response, and the status code. Then answer the three questions that separate a real contract from a drawing (9.6.1):
Is this write idempotent, and how? Any endpoint that spends money, sends a message or creates something the user can see needs an answer. The usual one is a client-generated idempotency key stored with a unique index, so a retried request returns the original result instead of creating a second thing (10.4).
How does the client page through a list? For feeds and timelines the answer is a cursor, not an offset, because offset pagination shows duplicates and skips items whenever the list changes underneath the reader — and feeds change constantly. Say the word cursor and say why in one sentence.
What does an error look like? One envelope shape for every endpoint, with a machine-readable code, a human message, and a request identifier the user can quote to support. This takes ten seconds to say and is the difference between an API and a pile of endpoints.
For anything slow — a video upload, a report, a bulk import — the endpoint returns 202 Accepted with a status resource the client polls, rather than holding a connection open for four minutes. This is the single most common API-shape mistake in system design rounds.
5. The data model, and the one sentence that decides it
Write the entities with their fields. Then write the access patterns as a small table: what query does the system actually run, how often, and what does it return? Then pick a partition key that serves those patterns, and justify it against the table you just wrote (10.6).
That order matters and is frequently reversed. Candidates pick a partition key that sounds sensible and then discover, three minutes later, that the main read pattern needs a scatter-gather across every partition. Deriving the key from the access patterns makes that impossible.
The rule in one sentence: partition by the thing that appears in the WHERE clause of your highest-volume query. Timeline reads are always "give me this user's timeline", so partition by user. Chat message reads are always "give me this conversation's recent messages", so partition by conversation. Redirect lookups are always "give me this code", so partition by code. When two access patterns want different keys, you need either a secondary index, a second copy of the data shaped for the second pattern, or an honest statement that the rarer pattern will be slower.
Two failure modes to name before the interviewer does. A hot partition happens when one key gets a disproportionate share of traffic — a celebrity account, a single popular product on sale day — and the fix is to split that key artificially into several sub-keys. A cross-partition transaction happens when one user action must change two partitions atomically, and the fix is either to co-locate the two things in one partition or to accept that the change becomes a saga with compensating actions (10.8.4).
6. Drawing the architecture: one path, drawn three times
The board fills up with boxes because candidates draw the system. Draw the request instead. Pick the highest-volume operation, start at the client, and walk it to storage and back, naming each component as the request arrives at it. One complete path beats twelve labelled boxes, because a path can be interrogated and a box cannot.
Then draw the same system twice more, small, beside it:
The write path, which is usually a different shape from the read path — validation, the store, and the event that fans out to everything downstream. Most systems in this Part are asymmetric, and drawing both paths is what makes the asymmetry visible.
The failure path, which is the one nobody draws and every interviewer values. What does the request do when the cache is empty, when the downstream service times out, when the queue is backed up? A third small panel showing the request falling back, shedding, or degrading is often the single most senior thing on the board.
Every study in this Part draws its architecture as a panel set for exactly this reason. Introduce each panel in a sentence before it appears, and explain every region after it — a diagram nobody narrates is decoration.
7. Deep dives: how to go three levels down
Minutes 25 to 40 are the graded part, and the interviewer will steer you: "tell me more about how the timeline is built". Going deep means three specific levels, in this order.
Level one — mechanism. How does the thing actually work, step by step, with data? Not "we use a cache" but "the timeline service reads the user's precomputed timeline list from Redis, which holds the most recent 800 entries as a sorted set keyed by user, and hydrates the tweet bodies from a second lookup."
Level two — failure. What breaks it, and what happens when it does? "If the Redis entry is missing — evicted, or the user has been inactive for a month — we fall back to assembling the timeline by querying the followee list and merging their recent tweets, which takes about 200 ms, and we then write the result back."
Level three — the alternative you rejected. What else could you have done, and what would it have cost? "The alternative is to assemble every timeline at read time. It removes all the fan-out machinery and the storage duplication, and for a user who follows 200 accounts it is a 200-way merge on the critical path. At 15,000 reads a second that is not affordable, which is why we precompute — but for the 0.1% of users who follow tens of thousands of accounts, read-time assembly is actually cheaper, which is where the hybrid comes from."
That last sentence is the shape of a senior answer: the alternative was not dismissed, it was priced, and its price turned out to be right for one specific slice of traffic. If you can only reach level one on every component, you read as someone who has assembled systems from tutorials. Level three on two components is worth more than level one on ten.
8. The Decision Ledger
The artifact that turns recitation into engineering. For each real choice, four columns:
| Decision | Alternatives | Why this | What it costs |
|---|---|---|---|
| Cursor pagination | offset; keyset + cache | drift-free while the list changes | no jump-to-page-7; totals need a second query |
| Fan-out on write | fan-out on read; hybrid | reads dominate 100:1 | write amplification; celebrities need the hybrid |
| Object storage for media | blobs in the database | database stays small and fast | a second store to secure and back up |
Three rules keep it honest. Every choice names a cost — a decision presented as free is a decision you have not examined, and the empty cost cell is exactly where an interviewer pushes. Alternatives are described fairly — a strawman ("we could store everything in one file") fools nobody and spends trust you will need later. The ledger is spoken, not just written — say "I'm choosing X over Y because of Z, and it costs me W" as you make each choice, so the ledger is a summary of the conversation rather than a table produced at minute 44.
The ledger outlives the interview. In a real design document it is the thing that lets a team three years later understand why a choice was made, notice that the reason has expired because the traffic shape changed, and replace it deliberately instead of reconstructing the reasoning from the code (10.19).
9. Scale and failure: the last five minutes
Two questions, answered concretely.
What changes at 10× and at 100×? The useful form of this answer names what breaks first, not what you would add. At 10× the timeline cache no longer fits in one machine's memory, so it shards by user. At 100× a single region cannot hold the write volume, so the system becomes multi-region and you now owe an answer about conflicts. Naming the breaking point in order shows you understand where the system's limits actually are.
What happens when each component dies? Put this in a table, because prose hides the gaps:
| What breaks | Blast radius | How you find out | What keeps it running | Recovery |
|---|---|---|---|---|
| Cache tier down | all reads hit the database | hit-rate alarm; latency p99 | in-process L1, request coalescing, shedding | warm from top-N list before restoring traffic |
| Primary database down | all writes fail; cached reads fine | write error rate | promote a replica; read-only degrade | replay the write queue |
| Queue backed up | staleness grows silently | consumer lag alarm | add consumers; drop low-value events | drain with lag as the exit condition |
The column people forget is how you find out. A failure mode with no detection is a failure mode you will learn about from a customer, and naming the specific alarm — consumer lag, cache hit rate, replica lag, error budget burn — is a signal that you have operated something rather than only designed it (10.10).
10. What interviewers actually grade
Five axes, one level up from the low-level-design rubric in 9.7.1:
Requirements handling. Did you scope, quantify and defer explicitly, or did you accept a vague prompt and start drawing?
Estimation driving the design. Do the numbers eliminate options, or do they decorate a design you had already decided on?
Structural soundness. Does the data model fit the access patterns? Is the partition key justified? Is it clear which component owns each piece of state? Is there an unaddressed single point of failure (10.4)?
Depth on demand. When pushed into a component, can you reach mechanism, failure and alternative?
Trade-off literacy. The ledger, delivered as conversation rather than recited at the end.
And the three failure modes that sink otherwise strong candidates. Drawing before scoping: boxes at minute three, requirements never. Breadth without depth: twelve components, none deep, and an interviewer who cannot find the bottom of any of them. Name-dropping without mechanism: "we'll use Kafka" with no answer to why a queue is not enough, what ordering guarantee you are buying, or what it costs to operate (10.1).
11. The recurring toolkit
Nearly every study in this Part composes the same eight moves. Learn them once here and each case study becomes an application rather than a new memorisation:
Cache in front of the read path. When reads dominate, the cache is not an optimisation, it is the serving tier, and it needs the same failure planning as a database (10.14.1).
Partition by whoever owns the access pattern — user, conversation, tenant, key range (10.6).
Push work off the request path into a queue. Anything not needed to answer the user goes asynchronous, with 202 and a status resource when the user cares about the result (10.8.1).
Outbox wherever a state change must reliably produce an event, because writing to the database and publishing to a broker are two systems that will eventually disagree (10.8.4).
Idempotency keys on every write that is not naturally repeatable (10.4).
Read models when the shape you write is not the shape you read — a precomputed timeline, a denormalised search document, a rolled-up counter.
The reliability ladder on every call that leaves the process: timeout, retry with jitter, circuit breaker, bulkhead, fallback (10.9).
The three-store split: blobs in object storage, metadata in a database, history in a log. This appears in more than half the studies in this Part.
What the interviewer will push on
"Why did you spend five minutes on requirements? I gave you a prompt." What they are checking is whether scoping is a habit or a performance. The tell is that your requirements produced numbers you later used — if the read/write ratio you asked for never appears again in your design, you were performing. The common wrong answer is to list requirements thoroughly and then design as if none of them existed.
"Your estimate says 6,000 reads per second. So what?" They are checking whether estimation is doing work. Every number needs the sentence after it: what it rules out. The tell is that you can name the option the number eliminated ("that is too much for one database, so the timeline has to be precomputed"). The wrong answer is to restate the number louder.
"You said you'd use a queue here. Why not just call the service directly?" This is the name-dropping probe, and it is asked in every round. The good answer names what the queue buys — the caller stops waiting, the downstream can be slow or briefly dead without failing the user, and traffic spikes get absorbed — and what it costs — the work now happens later so the user sees stale state for a while, delivery is at-least-once so the consumer must be idempotent, and there is a new thing to operate and monitor. The wrong answer is that queues are more scalable.
"What breaks first if traffic doubles tomorrow?" They are checking whether you know where your own system's limit is. A strong answer names one specific component, the number at which it fails, and the symptom you would see. A weak answer is "we'd add more servers", which is true of nothing in particular.
"You have five minutes left and I want to talk about the data model instead." They are checking whether you can drop a thread cleanly. Say what you are leaving unfinished in one sentence and move — do not finish your point at the cost of the thing they asked for. The interviewer steers because they are looking for a specific signal, and following the steer is nearly always the higher-scoring move.
Volunteer this, because nobody asks: the operational consequence of one of your choices. "The fan-out worker is the thing that will page someone at 3am, because when it falls behind, timelines get stale silently rather than erroring — so I'd alarm on consumer lag rather than on error rate, and the alarm threshold is the five-second staleness budget we agreed at the start." That sentence ties the requirement, the mechanism and the operational reality together, and almost nobody says it.
Next: 11.1 — the classic opener, run end to end through this method. It looks trivial and contains ID generation, a 100:1 read/write split, a cache that is the system, and a redirect budget measured in tens of milliseconds.
Recall
- First five minutes: functional (3–4 features) · non-functional with numbers · explicit out-of-scope. Clarifying questions that change the design: read/write ratio, what may be stale and for how long, DAU and peak multiplier, one region or many, largest object size, cost of five minutes down.
- Protocol: 0–5 requirements → 5–10 estimation → 10–15 API + data model (name the partition key) → 15–25 architecture → 25–40 deep dives → 40–45 scale, failure, ledger. Going backwards with a reason is fine; carrying a contradiction is not.
- Estimation constants: 86,400 s/day (use 100k) · 2.6M s/month · peak = 2–3× average · replication ×3 · indexes +20–50%. Every number gets a sentence naming what it rules out.
- Partition rule: partition by the field in the
WHEREclause of the highest-volume query. Name the hot-partition and cross-partition-transaction risks yourself. - Deep dive = three levels: mechanism (with data) → failure (what breaks, what happens) → the alternative priced, not dismissed.
- Decision Ledger: alternatives → choice → cost, spoken as you go. Every choice names a downside; alternatives described fairly.
- Failure table columns: what breaks · blast radius · how you find out · what keeps it running · recovery.
- Graded on: requirements handling · estimation driving design · structural soundness · depth on demand · trade-off literacy. Sunk by: drawing before scoping · breadth without depth · name-dropping without mechanism.
- Toolkit: cache the read path · partition by pattern owner · queue off the request path · outbox · idempotency keys · read models · reliability ladder · blobs/metadata/log split.
Self-test: Name the six clarifying questions and what each one changes. Convert 300M users × 2 timeline loads/day into peak QPS. What are the three levels of a deep dive? Give the ledger's four columns and its three honesty rules. Which column of the failure table do people forget?
Quiz Bank
FoundationalWalk the 45-minute protocol and say what each phase must produce.
0–5, requirements. Three or four functional features you will design, the non-functional targets as actual numbers (daily active users, read/write ratio, latency budget at a named percentile, staleness allowance, availability), and an explicit deferral list. The deferral is graded positively: it shows you know the system is bigger than the session.
5–10, estimation. Requests per second at average and at peak with a stated multiplier, storage per day and per year including replication and index overhead, and bandwidth if objects are large. Each number is followed by the sentence that matters: what it rules out. "40 TB a day of media" rules out keeping blobs in the database. "15,000 reads a second" rules out assembling the answer by query on the read path.
10–15, API and data model. Four or five endpoints with bodies, responses and status codes; the answers to the three contract questions (idempotency, pagination, error envelope); then entities, an access-pattern table, and the partition key justified against that table (10.6).
15–25, architecture. The highest-volume request walked from client to storage and back, through named components. Then the write path and the failure path as smaller panels beside it.
25–40, deep dives. Two or three components taken to mechanism, failure, and priced alternative. Follow the interviewer's steer rather than your own plan.
40–45, scale and failure. What breaks first at 10× and 100×, the failure table with detection included, and the ledger delivered as conversation.
The two questions to ask in every single design, because their answers reshape everything: the read/write ratio (10.2) and what may be stale (10.7.1).
AppliedConvert a prompt into numbers: 300 million daily users each loading a timeline twice and posting once every three days. Derive QPS and storage, and say what each figure forces.
Reads. 300M users × 2 loads = 600M timeline reads a day. Divide by 100,000 seconds (the rounded day) = 6,000 reads a second average. Apply a 2.5× peak multiplier = 15,000 reads a second at peak. What it forces: a single database cannot serve 15,000 timeline assemblies a second, where each assembly would be a merge across hundreds of followee feeds. The timeline must be precomputed into a per-user list and served from memory. That one number chose fan-out-on-write.
Writes. 300M ÷ 3 = 100M posts a day = 1,000 writes a second average, ~2,500 at peak. What it forces: very little. 2,500 writes a second is comfortable for a partitioned store, which means the write path may afford extra work — and that is exactly the budget the fan-out spends.
Storage. 100M posts a day × ~300 bytes (text plus identifiers plus timestamps) = 30 GB a day of post data. Times 3 for replication = 90 GB a day, plus roughly 30% for indexes ≈ 120 GB a day, or about 44 TB a year. What it forces: nothing dramatic. Text is cheap; this partitions across a modest cluster and stays there for years.
The number that changes the answer. Attach one 2 MB image to 10% of posts: 10M images a day × 2 MB = 20 TB a day before replication. What it forces: media leaves the database immediately and goes to object storage with only a URL kept in the row, and bandwidth rather than storage becomes the sizing constraint. Notice that the entire architecture pivoted on a question — "can posts have images?" — that takes five seconds to ask in the requirements phase and is expensive to discover at minute thirty.
The fan-out cost, which is the number people miss. 100M posts a day × an average of 200 followers = 20 billion timeline insertions a day, or 200,000 a second average. That is a real system on its own, and it is why the celebrity case needs a different treatment: one account with 100 million followers turns a single post into 100 million writes.
InterviewWhat is a Decision Ledger, and why does it matter more than the diagram?
A table of every significant choice with four columns: the decision, the alternatives you considered, why you picked this one, and what it costs. It matters more than the diagram because a diagram shows what you built while the ledger shows that you knew what you were choosing, and the second is the actual skill being measured. Anyone can draw a cache. Explaining that the cache is there because reads outnumber writes 100 to 1, that the alternative was read replicas which would have cost less operational complexity but not met a 50 ms budget, and that the cache costs you a thundering-herd failure mode you then have to design for — that is engineering.
Three rules keep it honest. Every choice names a cost, because a decision with no downside is a decision you have not examined, and the empty cost cell is precisely where an interviewer will push. Alternatives are described fairly, because a strawman signals inexperience and spends trust you will need in the deep dives. And the ledger is spoken as you go rather than produced at the end, so it reads as reasoning rather than as a summary slide.
Its value outlives the interview. In a real design document the ledger is what lets a team understand a decision years later, recognise that its justification has expired — the read/write ratio inverted, the product grew a second region, the object size grew tenfold — and change it deliberately. Without it, future engineers reconstruct the reasoning from the code, which usually means they assume there was none and either preserve the choice superstitiously or rip it out and rediscover the original problem the hard way.
It is also the cure for the most common interview failure. Technology name-dropping dies against the ledger format, because a product name in the "choice" column with an empty "cost" column is visibly unfinished, to you as well as to the interviewer.
StaffYou are designing the system-design interview loop for your company. What do you ask, how do you grade, and what do you refuse to test?
Ask open prompts in familiar domains, with a written clarification script so that every candidate who asks "can posts have images?" gets the same answer. Unscripted interviewers leak different scope to different candidates, and that variance is usually the loop's biggest fairness problem — larger than any disagreement about the rubric. Prefer prompts where product intuition is not the bottleneck (a URL shortener, a notification system, a chat) over ones that require niche domain knowledge (an advertising auction, a clearing house), unless the role genuinely needs that domain. Prepare two planned deep-dive steers per prompt, one about data modelling and one about a failure mode, so depth is probed consistently rather than wherever the interviewer's own interest happens to lie.
Grade on the five axes with anchored descriptors rather than adjectives. "Named the partition key and justified it against two stated access patterns" is something two interviewers can agree on. "Good data modelling" is not. Anchor the depth axis explicitly at the three levels — mechanism, failure, priced alternative — so that "went deep" stops meaning "talked for a long time".
Refuse to test memorised architectures of specific companies, which measures preparation rather than thinking and is defeated by any twist anyway. Refuse vendor trivia and configuration flags. Refuse whiteboard coding inside a design round, which is a different skill already tested elsewhere and which mostly measures context-switching. And refuse any prompt whose "right answer" is the interviewer's own production system, because that quietly rewards candidates who happen to share your history.
Calibrate by shadowing, by regrading transcripts against the anchors, and by watching per-interviewer score distributions. When one interviewer's scores are consistently a band below everyone else's, the problem is the interviewer, not a run of weak candidates, and only the distribution will tell you.
One thing to build into the loop that most companies miss: give the candidate the clock. Telling them "we are at minute twenty-five, I'd like to spend the next fifteen on the timeline" removes the time-management confound entirely, and time management is not the skill you are hiring for.
Flashcards
FlashThe six clarifying questions
Read/write ratio · what may be stale and for how long · DAU and peak multiplier · one region or many · largest object size · cost of five minutes of downtime. Ask three or four, say why as you ask.
FlashEstimation constants
100k seconds/day (86,400 rounded) · 2.6M seconds/month · peak = 2–3× average · replication ×3 · indexes +20–50%. Every number gets a sentence saying what it rules out.
FlashPartition key rule
Partition by the field in the WHERE clause of the highest-volume query. Derive it from the access-pattern table, never the other way round. Name the hot-partition risk yourself.
FlashThree levels of a deep dive
Mechanism with real data · what breaks and what happens then · the alternative priced rather than dismissed. Level three on two components beats level one on ten.
FlashFailure table columns
What breaks · blast radius · how you find out · what keeps it running · recovery. The detection column is the one candidates omit and interviewers notice.
Scenario Drill
DrillTen minutes into your design, the interviewer says: 'Actually, assume this is a global product with writes in three regions, and that a stale read is unacceptable for one specific field.' Rework your method, not your architecture, and say what you would change and in what order.
First, stop and re-scope rather than patching. Two of the requirements you wrote down at minute three have just been replaced. Say so out loud and rewrite them on the board — a single-region assumption and an "everything may be a little stale" assumption were both doing quiet work in every decision you have made since, and silently carrying on is how a design ends up internally inconsistent by minute thirty.
Second, ask the one question the change actually turns on: which field, and what happens if two regions disagree about it? This matters more than any technology choice. If the strict field is something like an account balance or a seat allocation, then that field has one owner and cross-region writes to it must be routed to that owner, which is a routing problem with a latency cost you can state (a write from Sydney to a European owner costs roughly 250 ms of round trip, so the product has to accept a slower write for that one operation). If the strict field is something like a username's uniqueness, you need a single global allocator or a partitioned namespace so that two regions cannot mint the same value at all. These are different designs, and the word "consistency" alone does not tell you which one you need (10.7.1).
Third, redo the estimation you already did, because two numbers changed. Traffic now splits across three regions, which lowers per-region QPS and may soften a bottleneck you had designed around. And a new number appears: cross-region round-trip latency, roughly 80 ms within a continent and 150–250 ms between them. Any operation that now needs a remote round trip has just spent most of its latency budget, so write the budget down again and see which endpoints still fit. This is the phase-two-again move from Figure 1, and doing it openly is the point.
Fourth, separate the data into three buckets on the board, because this is what makes the rest of the answer fast. Bucket one: data that is read everywhere and written rarely (product catalogue, configuration) — replicate everywhere, accept seconds of staleness, no coordination. Bucket two: data owned by one user or tenant who is physically in one place (their profile, their orders) — pin it to a home region, and the rare cross-region read is a cache miss with a slow path. Bucket three: the strict field — one owner, synchronous, and the latency cost stated honestly. Almost every global design reduces to sorting the data into these three buckets, and doing the sort explicitly is what stops "we'll use multi-region" from being a phrase rather than a design (10.5).
Fifth, update the ledger rather than the diagram. The rows that change are the interesting output: "single-region primary" becomes "region-pinned ownership with routed writes for the strict field", the alternative is now genuinely multi-master with conflict resolution, and the cost you name is that a small set of operations became slower and one component — the router that knows who owns what — became something that must never be wrong. Naming that new single point of failure yourself, and saying how it is replicated and how a stale routing table is detected, is the strongest thing you can do with the last two minutes.
What should not change, and say so: the API shape, the access-pattern table, and the partition key, because those were derived from what users do, and users did not change. A twist that alters deployment topology but not access patterns should leave most of the data model standing. If it does not, that usually means the original model was fitted to the deployment rather than to the workload.