Six questions turn a system design prompt into requirements, and they take about 8 minutes.
On this page
Daily active users. The read to write ratio. What must never break and what may be stale.
What is out of scope. Whether something already exists. Which number means success.
“Design Twitter” is a prompt. The interviewer waits to see whether you turn it into a problem.
Candidates who draw boxes in minute 2 design something nobody asked for.
1. Who uses this, and how many daily?
Ask for daily active users, not registered users. They differ by an order of magnitude.
50,000 daily users fit on 1 machine. 50 million do not.
If the interviewer says “you tell me”, pick a number out loud. “I will assume 10 million daily active.”
“If that is off by 10x either way, 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 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.
Where the cache goes, whether replicas help, which key you shard on. All of it depends on this.
3. What must never break, and what may be stale?
Ask it concretely. “If this component is down for 10 minutes, what does the user see?”
In most systems only 1 or 2 paths need 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.
4. What is out of scope?
“I am not designing authentication, the mobile client, or the analytics pipeline. Tell me if one of those is the point.”
That costs 15 seconds. A finished design of 1 thing scores above an outline of 5.
5. Is something already there?
A real engineer asks this, and it surprises interviewers in a good way.
If a system exists, ask what is wrong with it. A known failure gives the design a purpose.
If it is greenfield, you lost 10 seconds and showed judgement.
6. What does success look like in a number?
p99 latency, uptime, cost per million requests, time to recover. Ask which one they care about.
A design tuned for latency looks different from one tuned for cost. Never ask, and you optimise for the one you happen to like.
System design requirements, sorted: functional and non-functional
Questions 1, 4 and 5 give you functional requirements: who, what, and what not.
Questions 2, 3 and 6 give you the non-functional ones. Load, consistency, and the number you are judged on.
Interviewers score both. Most candidates only gather the first kind.
System design requirements example, on the board
Write them down 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 them out loud every time you make a choice.
“I am adding a cache here. Reads are 100 to 1, and 30 seconds of staleness is allowed.”
That sentence is worth more than the cache. It shows the design follows the requirements, not a memorised pattern.
The system design requirements follow-up that catches people
Halfway through, a good interviewer changes something. “Actually, this needs to be strongly consistent.”
They are testing whether you know which part of your design depended on that assumption.
If you wrote the system design requirements down, this is easy. “That kills the read replica story.”
“The cache becomes read-through with invalidation on write. p99 goes up. Here is the new bottleneck.”
Without the numbers written down, you 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.
The minute-by-minute procedure is in the system design interview playbook.
To be scored on it, book a system design mock interview.