The Design Playbook
A playbook for any “design X” question
“Design Twitter.” Your stomach drops. Not because it is hard — because it is shapeless. This lesson gives the shapeless question a shape: four steps, always the same, that turn panic into a plan.
- Clarify requirements. Ask who uses it, what they do, and how many of them there are. Scope aggressively — designing “Twitter” means picking two or three features, not forty. End with two lists: functional requirements (what it does) and non-functional (how fast, how big, how available).
- Estimate. Run the back-of-the-envelope: QPS, storage, bandwidth. These numbers decide everything downstream — whether one database suffices or you need shards, whether a cache is optional or mandatory.
- Sketch the high-level design. Draw the boxes and arrows both sides agree on: client, load balancer, web servers, database, cache, queue. Say each box's job out loud as you draw it — this is the shared map for the rest of the conversation.
- Deep dive. Pick the one or two components where the real difficulty lives and drill in: the schema, the algorithm, the failure modes. Defend every choice as a trade-off — what you gained, and what you knowingly gave up.
Two excellent engineers will design the same system differently — and both can be right, because every design is a bundle of trade-offs argued well. Consistency versus latency, simplicity versus scale, build versus buy. The CAP idea is the famous example: during a network partition, a distributed system must choose between consistency (refuse to answer until it is sure) and availability (answer with what it has, maybe stale). You cannot have both at that moment — you can only choose, and explain why.
The design is the excuse; the conversation about trade-offs is the point. Nobody grades your boxes — they listen to whether you know what each box costs.
At each step, a different skill is under the microscope. Step 1: do you scope, or dive in blind — starting to draw before asking is an instant red flag. Step 2: do your numbers drive decisions — estimates that never change a choice are decoration. Step 3: do you get agreement before drilling — the high-level sketch is a contract, and reviewers watch whether you negotiate it. Step 4: do you defend trade-offs, or recite tools — naming a technology is worth nothing next to saying what it costs and why you pay it.
Jumping to tools is the giveaway of a beginner: “Kafka” before saying what problem it solves, “Kubernetes” before knowing the load. Name the problem first — decoupling, buffering, retries — then let the tool earn its place. A tool in search of a problem is complexity with a logo.
Each step has its own way to fail. Step 1: skipping clarification — you design for the wrong product and no brilliance after that saves you. Step 2: estimation with no consequences — you compute 11,600 reads/s and then build as if you never ran the number. Step 3: drawing boxes nobody agreed on — you solve your version of the problem, not theirs. Step 4: deep-diving the easy component instead of the hard one — perfecting the database schema while the feed ranking, the actual difficulty, stays a gray box.
Someone asks you to “design a chat app.” What are your first three moves before drawing a single box? (Ask who and how many users, pick the two features in scope — say 1:1 messages and delivery receipts — then estimate QPS and storage. Only then do boxes appear.)
Every design question is the same four steps: clarify the requirements, estimate the numbers, sketch the boxes, deep-dive the hard parts. And remember what you are really being asked: not for the right design, but for trade-offs argued well.
Take a system you use daily — your bank app, a food delivery app, your company's dashboard — and run steps 1 and 2 on it in a notebook: write the functional and non-functional requirements, then estimate QPS and storage. Ten minutes, no drawing allowed.
The Design Playbook