Before any caching or sharding, you need a way to drive the conversation. This is the repeatable script strong candidates run on every problem.
⏱ 30 minPrereq: noneYou'll be able to: structure any design problem in the first 5 minutes
By the end of this unit
Run the 7-step framework on any prompt, out loud, without freezing.
Split requirements into functional vs non-functional — the split interviewers care about most.
Budget your time across a 45-minute interview so you never run out before the deep dive.
Know what the interviewer is actually writing on their scorecard.
Why a framework at all?
A system design interview is deliberately under-specified. "Design Instagram" has a thousand valid answers. The interviewer isn't checking whether you memorized one — they're watching how you reduce an open problem to a concrete, defensible design, and whether you communicate while doing it. A framework gives you a backbone so your working memory is free for the actual engineering.
The one-liner to open with
"Let me start by clarifying the requirements and the scale we're targeting, then I'll sketch an API and data model, draw a high-level architecture, and we can deep-dive wherever you'd like." Saying this in the first 30 seconds signals seniority instantly.
The 7-step framework
Steps 1–5 are linear setup (~15 min). Step 6 is where most of the score is won. Step 7 closes strong.
1 · Clarify requirements (3–5 min)
Split into two buckets and write them where the interviewer can see them:
Functional
What can a user do? ("post a photo", "view a feed")
Pick 2–3 core features. Explicitly de-scope the rest: "I'll skip DMs for now — OK?"
This bounds the whole problem.
vs
Non-functional
How well? Scale, latency, availability, consistency, durability.
"Read-heavy or write-heavy?" "How fresh must data be?"
These drive every later tradeoff.
Don't skip de-scoping
Trying to design everything is the #1 way juniors run out of time. Naming what you're not building is a seniority signal, not a weakness.
2 · Estimate scale (3–5 min)
Daily active users → requests/sec, storage/day, bandwidth. You don't need precision; you need the order of magnitude that tells you whether one box works or you need 100. Unit 02 is entirely this skill.
3 · Define the API (3 min)
A handful of endpoints pins down the contract between client and system: POST /media, GET /feed?cursor=…. It forces you to name inputs, outputs, and pagination before you draw anything.
4 · Data model (3 min)
Core entities and their relationships: User, Post, Follow, Like. Deciding what's relational vs what's a blob informs your storage choice (Units 03–04).
5 · High-level design (5 min)
Draw the boxes: clients → load balancer → app servers → cache → database, plus object store, queue, CDN as needed. Keep it legible. Talk through the path of one write and one read.
6 · Deep dive (10–15 min) — the main event
The interviewer steers here, or you propose: "The feed read path is the bottleneck — want me to dig in?" This is where caching, sharding, fan-out, and consistency tradeoffs earn your score. The rest of this course is fuel for step 6.
7 · Wrap up (2–3 min)
Name the biggest tradeoff you made, one failure mode and how you'd handle it, and what you'd do with more time. Ending on tradeoffs leaves a senior impression.
Time budget — a 45-minute interview
~5m
Clarify + scope
~5m
Estimate + API + data
~7m
High-level design
~20m
Deep dives
~5m
Wrap + Q&A
Keep a clock in your head If you're 20 minutes in and still drawing boxes, cut and move to a deep dive. Reaching a bottleneck discussion matters more than a perfect diagram.
What's actually on the scorecard
Signal
What earns it
Handling ambiguity
Asking sharp clarifying questions; stating assumptions out loud.
Structured thinking
Following a visible process instead of jumping to a random component.
Technical depth
Going beyond buzzwords — why Redis, how sharding rebalances.
Tradeoff awareness
"X buys us latency but costs consistency" — naming both sides.
Communication
Narrating your thinking; the interviewer never has to guess.
Prioritization
Spending time on what matters; de-scoping the rest.
Common failure Silence. A correct design built in your head with no narration scores poorly. Think out loud — even wrong-but-stated beats right-but-silent.
Quick check
You're 22 minutes into a 45-minute interview and still refining the data model. What's the best move?
Move to the deep dive. Most of the score lives in step 6. A reasonable-but-imperfect model you can defend beats a flawless one that leaves no time to discuss scaling, caching, or failure. Time management is itself a scored signal.
Quick check
"The system should stay up during a data-center outage" is a…
Non-functional. It describes how well the system behaves, not what a user can do. Availability, latency, durability, and consistency are the non-functional levers that drive your architecture choices.
Your reusable opening checklist
Tap each as you internalize it — this is the script to run in the first 5 minutes of every interview:
Restate the problem in one sentence and confirm it.
List 2–3 functional requirements; explicitly de-scope the rest.
Ask the key non-functionals: scale, read/write ratio, latency, consistency, availability.
Do a rough scale estimate (DAU → QPS → storage).
Sketch the API contract for the core actions.
Propose where to deep-dive and check with the interviewer.
Practice before you move on
Set a 5-minute timer. Out loud (really — say it), run steps 1–2 for: "Design a URL shortener." List functional vs non-functional requirements and one rough scale estimate. If you can narrate it without stalling, you're ready for Unit 02.