Fundamentals
Scoping the Problem
The first ten minutes decide the interview, and they happen before you draw anything.
Read the full guide →The prompt is deliberately vague: "design Twitter" has no scope, and the interviewer is watching whether you invent one or start drawing boxes
Functional requirements: name the two or three user journeys you will support and say out loud what you are cutting. A design that does everything demonstrates nothing
Non-functional requirements are the ones that shape architecture: scale, latency target, consistency needs, availability. Ask for them, and if the interviewer shrugs, propose numbers yourself
Turn adjectives into numbers: "fast" becomes p99 under 200 ms, "lots of users" becomes 10M DAU, "always available" becomes three nines and a defined failure mode
Read-write ratio first: it decides caching, denormalisation and replication before any component is chosen. A 100:1 read-heavy system is a different design from a write-heavy one
Back of the envelope in this order: DAU to QPS, QPS to storage per year, storage to bandwidth. Round hard, because you want an order of magnitude, not accuracy
State the scope back before moving on: "so we are building X for Y users at Z reads per second, ignoring A and B". That sentence is the contract for the rest of the hour
Write the constraints somewhere visible and refer back to them. Every later trade-off should be justified against a number you agreed at the start
When to use: The opening of every system design interview, and any real design doc. Ten minutes of a 45 minute interview is the standard split.
Trade-off: Time spent scoping is time not spent designing, and an interviewer who wanted depth can read a long requirements phase as stalling. Timebox it, keep it conversational rather than a checklist recital, and move on as soon as you have the handful of numbers that constrain the architecture. Scoping earns its place by making later decisions defensible, not by being thorough for its own sake.