LESSON 2.1
A framework for any design
Five steps, always in the same order, that keep a 45-minute design focused, complete and easy to follow.
5 min read
A system design interview is 45 to 60 minutes to turn one vague sentence ("design Twitter") into a design you can defend. Real design reviews are the same, just with more time. Without a structure it is easy to spend 20 minutes on database schemas and never draw the system.
This module teaches a framework that works for any problem. It is five steps, done in order:
- Requirements (about 5 minutes). What the system must do, and how well: scale, latency, consistency, availability.
- Core entities (about 2 minutes). The handful of nouns the system manages: User, Link, Post, Booking.
- API (about 5 minutes). The endpoints that satisfy each functional requirement.
- High-level design (about 10–15 minutes). Boxes and arrows that serve every API call, kept simple.
- Deep dives (about 10–15 minutes). Revisit the non-functional requirements and harden the design: scale, failures, consistency, the hard parts.
Why this order works
Each step feeds the next:
- The requirements tell you which entities matter and which qualities to optimize.
- The entities tell you what the API reads and writes.
- The API is a checklist: the high-level design must serve each endpoint.
- The high-level design shows which parts are under the most pressure, which is exactly where the deep dives go.
It also protects you from the two classic failures: designing a beautiful system for the wrong requirements, and running out of time before the design is complete.
Simple first, then better
In step 4, it is fine, and in fact smart, to draw a design you know will not scale. A single database for a URL shortener serving 10 billion redirects a month? It will not survive. But it proves the system works end to end. In step 5 you then say "this database is the bottleneck: 4,000 reads a second at peak. Let's add a cache and read replicas," and the design gets better in a way the interviewer can follow.
This is also how real systems are built: start simple, measure, fix the thing that breaks.
What each step produces
| Step | You end up with |
|---|---|
| Requirements | 3–5 functional requirements, 3–5 specific non-functional ones, things out of scope |
| Core entities | A short list of nouns, maybe their key fields |
| API | One endpoint (or event) per functional requirement |
| High-level design | A diagram that serves every endpoint; a request traced through it |
| Deep dives | 2–3 parts of the design improved, each tied to a requirement |
Try it
URL Shortener HLD
Keep this problem open as you read the module; each lesson applies one step to it.