Why a framework
Open-ended questions are easy to get lost in. You go deep on the database before you've decided what the API is, or run out of time before anyone has seen a working design. A framework is a fixed order of steps that keeps you moving, makes sure you cover the basics, and leaves time for the interesting parts.
Every design lesson in this course uses the same six steps, so by the end of Part 3 they'll be habit.
The six steps
- 01
Requirements
~5 min. Core features, scale, key qualities.
- 02
Estimates
~2–5 min. Only those that change a decision.
- 03
Entities & API
~5 min. The data and the calls.
- 04
High-level design
~10–15 min. Boxes and arrows that work end to end.
- 05
Deep dives
~10–15 min. The hardest or busiest parts.
- 06
Wrap-up
~3–5 min. Bottlenecks, failures, growth.
The times are a guide, not a rule. If the interviewer wants to spend twenty minutes on one deep dive, follow them.
1. Requirements
Write down three or so core features, an out-of-scope list, and the non-functional requirements that matter, with numbers (01.02 Functional and non-functional requirements). For Snip: create a short link, redirect, see click counts; 10M links a month, 100 reads per write; fast, always-available redirects; never lose a link.
2. Estimates
Do the few calculations whose answers change the design (01.05 Back-of-the-envelope estimation). For Snip: about 1,000 redirects a second at peak and 300 GB over five years. Then say what it means: "read-heavy, and it fits on one database".
3. Core entities and API
Name the main things the system stores, then the calls clients make. Keep it short; this is the contract the rest of the design has to satisfy.
Link { code, long_url, owner_id, created_at }
Click { code, at, country, referrer }
POST /links { long_url } → 201 { code, short_url }
GET /{code} → 302, Location: long_url
GET /links/{code}/stats → 200 { clicks, by_day }4. High-level design
Draw the simplest set of components that serves every core requirement, and walk one request through it to prove it works. Build it one requirement at a time: here's Snip's redirect path, the one that matters most.
5 steps. Use Next and Back to follow the request.
Text version
- A redirect arrives at the load balancer, which picks one of the API instances.
- The API looks the code up in the cache. With 100 reads per write, most lookups end here.
- On a cache miss it reads the database, and puts the answer in the cache for next time.
- It drops a click event on a queue instead of updating counts itself, so the redirect stays fast.
- A worker reads clicks from the queue and updates the counts. They can lag a little, which the requirements allow.
- Browser → Load balancer
- Load balancer → Snip API
- Snip API → Cache: 1st
- Snip API → Database: on miss
- Snip API → Click queue: click
- Click queue → Stats worker
- Stats worker → Database: counts
You'll learn each of these components in Part 2. For now, notice that every one is justified by something in steps 1 and 2. If you can't say which requirement a box serves, it probably shouldn't be there.
5. Deep dives
Pick the two or three parts where the design is hardest, busiest or riskiest, and go into detail: compare options, name what each costs (01.06 Trade-offs: there is no best design), and choose. For Snip, good candidates are:
- How short codes are made so they're short, unique and hard to guess.
- Keeping the redirect path fast and available, including what happens when the cache or database fails.
- Counting clicks accurately without slowing down redirects.
At senior levels, you're expected to choose these yourself. If you're not sure what the interviewer wants, ask.
6. Wrap-up
Finish by stepping back: where's the bottleneck now, what fails first, and how would the design change at ten times the traffic? This shows you see the design as something that keeps evolving, not a finished drawing.
You're 10 minutes into a 45-minute interview and have a clear set of requirements. The interviewer hasn't asked about any particular area. What's the best next move?
Try it
Run all six steps on a Pastebin: users paste text (up to 1 MB) and get a link anyone can open to read it. Assume a million new pastes a day and 10 reads per paste. Keep each step short; the goal is to practise the order.
Recap
Interview questions
Walk me through how you'd structure a 45-minute system design interview.