The system design interview framework

A system design interview gives you a one-line prompt, such as "design a URL shortener" or "design WhatsApp", and 45 minutes. There is no single right answer. The interviewer is not checking whether you can reproduce a blog post. They want to see how you take an ambiguous problem, turn it into concrete requirements and numbers, propose a design that works end to end, and then find and fix the parts that break under load or failure. Senior engineers do the same thing at work when they write a design doc.

Most candidates who fail do not fail on knowledge. They fail on structure. They spend 20 minutes on requirements, or draw boxes for 30 minutes and never go deep, or go deep on the wrong thing. A fixed framework solves that. It frees your attention for the problem, because you never have to wonder what comes next.

The 45-minute timeline

Interviews at large tech companies usually run 45 to 60 minutes, with about 5 minutes for introductions and 5 for your questions. Plan for roughly 40 minutes of design. A good default budget:

Step	Minutes	What you produce
Requirements	5	3 to 5 functional requirements, and 3 to 5 non-functional requirements with numbers
Estimates	3	QPS, storage and bandwidth, only where they change the design
API	5	The 3 to 6 endpoints or messages that cover the functional requirements
Data model	5	Core entities, keys, and which store holds each one
High-level design	10	A box diagram that satisfies every functional requirement
Deep dives	15	Two or three hard problems solved properly, with trade-offs
Wrap-up	2	Bottlenecks, failure modes and what you would do next

The numbers are a budget, not a law. Follow the interviewer's lead, but keep the shape in mind, so you notice when you have spent 12 minutes on requirements.

Tip

Write the step names on the whiteboard, or in a corner of the virtual canvas, before you start. It shows the interviewer you have a plan, and it lets you tick the steps off.

Reading order

Step	Concept	What it answers
1	Requirements and estimates	What must the system do, and how big is it?
2	APIs and data models	What is the interface, and where does each piece of data live?
3	High-level design, deep dives and trade-offs	How does the design work, and which hard parts do you solve?
4	What interviewers score	How do interviewers judge you, and what changes by level?

Practicing

Reading case studies builds vocabulary. It doesn't build the skill of producing a design under time pressure. You need reps.

Timed write-ups. Pick a prompt, set a 45-minute timer, and produce the full template. Compare with a reference solution, and write down the two biggest gaps.
Mock interviews. Practice with a peer who interrupts with "why?". Swap roles too. Seeing a rambling answer from the interviewer's side is valuable.
Real architectures. Engineering blogs from companies such as Discord, Slack, Uber, Netflix, Meta and Stripe explain why a system looks the way it does, and what broke first.
Building blocks. When a mock exposes a gap, such as replication lag or hot partitions, study that block before the next mock.

Aim for ten to fifteen timed reps across read-heavy, write-heavy, real-time, consistency, geo and pipeline problems. The broader plan is in interview prep strategy.

The one-page template

Copy this into a doc and fill it in for every practice problem.

PROBLEM: ______________________

1. REQUIREMENTS (5 min)
   Functional (3–5):    1. ___  2. ___  3. ___
   Out of scope:        ___
   Non-functional:      scale (DAU, QPS) ___  latency (p99) ___
                        availability ___  consistency ___  durability ___

2. ESTIMATES (3 min)    read QPS ___  write QPS ___  peak ×___
                        storage/yr ___  bandwidth ___  memory for hot set ___
                        → implication: ___

3. API (5 min)          endpoint / message  → response   (auth, pagination, idempotency)

4. DATA MODEL (5 min)   entity: key fields, PK/partition key, store, source-of-truth or derived

5. HIGH-LEVEL DESIGN (10 min)
   Diagram + walk each functional requirement through it

6. DEEP DIVES (15 min)  for each of 2–3:
   problem (with a number) → options → trade-offs → choice → what it costs

7. WRAP-UP (2 min)      bottlenecks, failure modes, monitoring, what changes at 10×

Key takeaways

Budget the time: about 5, 3, 5, 5, 10, 15 and 2 minutes for requirements, estimates, API, data model, design, deep dives and wrap-up.
Protect the deep-dive time. Level is decided there.
Every estimate should justify a component. Numbers that change nothing are noise.
Interviewers score problem navigation, solution design, technical depth and communication.
Practice with timed write-ups and mocks, not just reading.

In practice

A real design doc has the same skeleton: requirements, estimates, interfaces, data model, architecture, risky details, alternatives and open risks. Engineers who run this loop quickly in a meeting get trusted with bigger systems.