Six questions turn a system design prompt into requirements, and they take about 8 minutes. Daily active users.
On this page
The read to write ratio. What must never break and what may be stale. What is out of scope. Whether something already exists.
The fifth is which number means success.
“Design Twitter” is a prompt. The interviewer waits to see whether you turn it into a problem.
Candidates who start drawing boxes in minute 2 design something nobody asked for.
1. Who uses this, and how many of them are there daily?
Ask for daily active users, not registered users.
Daily and registered users differ by an order of magnitude. The difference decides your design.
50,000 daily users fit on 1 machine. 50 million do not.
If the interviewer says you tell me, pick a number out loud.
Say what changes if the number is off by 10x.
“I will assume 10 million daily active.
If that is off by 10x in either direction I will say what changes.” Now you have a stake in the ground and permission to move.
2. What is the read to write ratio?
The single most useful number in the room, and hardly anyone asks for it.
A system read 1,000 times per write is a caching problem. A 1:1 system is a write throughput problem.
One written more than it is read, like telemetry, is a different machine again. Where the cache goes depends entirely on this.
Whether replicas help depends on it too. So does whether you shard on write or on read key.
Whether a queue buys you anything depends on it as well.
3. What must never break, and what may be stale?
Ask the question concretely. If this component is down for 10 minutes, what does the user see?
In most systems only 1 or 2 paths genuinely require strong consistency.
The rest can be seconds behind unnoticed.
Follow up with how stale is too stale. 5 seconds and 5 minutes lead to different designs.
Interviewers rarely volunteer that number unless you ask.
4. What is out of scope?
Say what you are not designing and get agreement before you start.
I am not going to design authentication, the mobile client, or the analytics pipeline.
Tell me if any of those are actually the point.
Naming what is out of scope costs 15 seconds. A finished design of 1 thing scores above an outline of 5.
Without it you will gesture at 8 subsystems and finish none of them.
5. Is this a new system or is something already there?
The question about an existing system surprises interviewers in a good way. A real engineer asks it.
If a system already exists, ask what is wrong with it.
A known failure gives the design a purpose. Fix the specific failure, rather than build a monument.
If it is greenfield, say so and move on. You lost 10 seconds.
Asking anyway shows judgement, and judgement is what senior rounds score.
6. What does success look like in a number?
Latency at the 99th percentile, uptime, cost per million requests, time to recover. Ask which one they care about.
A design tuned for p99 latency looks different from one tuned for cost.
If you never ask, you will optimise for whichever you happen to like.
Half the time that will be the wrong one.
What do you do with the system design requirements?
Write them on the board and keep them visible. 4 or 5 lines is enough.
10M DAU, 20 req/user/day
~2,300 rps avg, ~7,000 peak
read:write 100:1
feed may be 30s stale, posts may not be lost
out of scope: auth, mobile, analyticsRefer back to the written system design requirements out loud. Do it every time you make a choice.
“I am adding a cache here. Reads are 100 to 1, and 30 seconds of staleness is allowed.”
A sentence tying the cache to the numbers is worth more than the cache.
The sentence shows the design follows the system design requirements. It is not a memorised pattern.
The interviewer will change a requirement later. You can change the design instead of defending it.
The system design requirements follow-up that catches people
Halfway through, a good interviewer changes something.
“Actually, this needs to be strongly consistent.” Or: “What if it is 100 times bigger?”
Interviewers are testing whether you know which part of your design depended on that assumption.
If you wrote the numbers down, this is easy. “That kills the read replica story.
The cache has to become read-through, with invalidation on write. My p99 goes up. Here is the new bottleneck.”
If you did not write them down, you will redesign from scratch. And run out of time.
Common questions
How long should the requirements phase take?
About 8 minutes of a 45-minute round, and no more than 10. Still on requirements at minute 20 means you will not finish. Drawing boxes at minute 3 means you are guessing. Say the time budget out loud at the start. The interviewer then knows you are managing it deliberately.
What if the interviewer refuses to answer your questions?
Answer them yourself, out loud, and label them as assumptions. I will assume 10 million daily active and a 100 to 1 read ratio. I will say what changes if either is wrong. A stated assumption scores almost as well as a given requirement. It keeps the round moving.
Do these questions work for a take-home design task?
Yes, and you write the answers into the document instead of onto a board. Put them in the first section, before any diagram. A reviewer reading 12 submissions notices the one that states its assumptions. It is the only one they can evaluate without guessing.
Is asking too many questions a bad signal?
Six is not too many, and 15 is. The line is whether each question changes something in the design. If you cannot say what you would do differently with the answer, skip it. Interviewers score requirement-gathering, and they also score whether you can stop gathering.
What makes a good system requirement?
A number and a boundary. “100,000 daily users, 10 reads per write” is a requirement. “It should be fast” is not. A good requirement tells you what to build and what to skip. If it does not change your design, it was not a requirement.
The short version
Daily active users. Read to write ratio. What may be stale. What is out of scope. Is something already there.
What number means success.
8 minutes, 6 answers, written on the board. Then design to them, out loud, and every later question becomes answerable.
The full minute-by-minute procedure is in the system design interview playbook.
You can be scored on it instead of reading about it.
A mock interview is 60 minutes and 100 euro.