The 8-Step Framework
Requirements → capacity (only when it changes a decision) → entities → API → data flow → high-level design → deep dives → wrap-up, with time budgets and what mid-level depth looks like at each step.
Why you need a framework at all
The number one way mid-level candidates fail system design interviews is not a missing piece of knowledge. It is not delivering a complete working system — running out of time because they rabbit-holed on one component, over-polished the API, or wrote low-level code nobody asked for. A fixed framework fixes this: you always know what step you are on, what "done" looks like for that step, and how many minutes it deserves.
The framework below is the modern consensus shape (it is essentially Hello Interview's delivery framework, and Alex Xu's 4-step method expanded). Use the same template for every question — Bitly, Twitter, Uber — so the structure is automatic and all your thinking goes into the actual design.
The eight steps
| # | Step | What you produce | Time (45-min interview) |
|---|---|---|---|
| 1 | Requirements | Top 3 functional features + quantified non-functional targets | ~5 min |
| 2 | Capacity estimation | A few numbers — only when they change a decision | 0-2 min, inline |
| 3 | Core entities | 3-5 nouns the system is about | ~2 min |
| 4 | API design | 4-5 endpoints, one per functional requirement | ~5 min |
| 5 | Data flow | High-level pipeline narration — pipeline systems only | 0-5 min, often skipped |
| 6 | High-level design | Boxes and arrows satisfying every functional requirement | 10-15 min |
| 7 | Deep dives | 2-3 hardened areas driven by the non-functional requirements | ~10 min |
| 8 | Wrap-up | Recap against requirements + what you'd do next | 2-3 min |
Two steps are conditional by design. Capacity estimation is not a ceremony you perform up front; you state scale assumptions in requirements and run arithmetic later, at the exact moment a number decides something ("does this fit in one database?"). Data flow only exists for systems that are fundamentally a processing pipeline — a web crawler is "fetch → parse → extract → store → repeat" before it is any set of boxes. For a CRUD product like a URL shortener, skip it and say you are skipping it.
What each step is for, in one breath
Requirements define the scope you will be graded against — get them wrong and everything after is answering the wrong question. Entities establish shared vocabulary (User, Tweet, Follow) without full schemas. The API is the contract: one endpoint per functional requirement, sketched quickly. The high-level design is where you draw the system and walk each endpoint through it end to end — client, load balancer, service, database — narrating what happens at every hop. Deep dives return to your non-functional requirements and fix the weak spots: the slow read path gets a cache, the double-booking race gets a lock. The wrap-up closes the loop: "posting works via X, the feed meets 500ms via Y" — ending on a completed, requirement-checked system instead of mid-tangent.
The mid-level bar at each step
Knowing the steps is not enough — you need to know how deep each one goes at your level. The leveling research is consistent on three axes:
Breadth over depth (about 80/20). A mid-level candidate must assemble all the major components of a working, scalable service and be able to explain every box they draw — if you add an API gateway, expect "what does it do and why do we need it?" Nothing on your whiteboard is taken for granted. What you are not expected to have is production war stories or staff-level depth; discussing concepts somewhat academically is fine. Senior flips the ratio: clear the basics fast, then go genuinely deep in two chosen areas.
The interviewer drives. At mid-level it is normal — and not a negative signal — for the interviewer to pick the deep-dive topics and steer the pace. Your job is to respond crisply and structurally when steered. Proactively leading two or more deep dives unprompted is senior signal; nice if it happens, not the bar.
"Good" beats incomplete "great." On concrete problems there is usually a good-tier answer and a great-tier answer (for seat locking: a status column with an expiry job is good; a Redis lock with a TTL is great). Landing the good tier everywhere beats reaching the great tier in one place and never finishing the system.
The one technique that protects your time
While drawing the high-level design you will constantly spot future problems: "this naive feed query won't scale." The winning move is to flag it verbally and keep moving: "I know this won't hold at scale — I'll fix it in the deep dives." This does three things at once: it shows the interviewer you saw the problem, it creates your deep-dive agenda for step 7, and it protects step 6's real goal — a simple system that fully satisfies the functional requirements. Optimizing mid-draw is how designs end up 60% finished at minute 40.
What this module covers
The next three lessons take the steps in order — requirements and smart estimation, then entities and API design, then high-level design and deep dives. After that, a full walkthrough applies all eight steps to the classic warm-up question, a URL shortener, which becomes the reference example for every question you practice later. The checkpoint quiz at the end tests the framework itself: ordering, time budgets, when to estimate, and how to pick deep dives.
Learn the template once. Then every interview becomes the same interview.