System Design Interview Framework
A repeatable structure for turning an open-ended prompt ("design X") into a 45-minute conversation that covers requirements, scale, architecture, and trade-offs — without freezing or rambling.
Problem it solves
System-design interviews are unstructured on purpose: the interviewer wants to see how you organize ambiguity, not whether you memorized one diagram. Without a framework, candidates either freeze on "where do I start" or jump straight to an architecture that ignores the actual requirements. A repeatable sequence of steps turns 45 minutes of open space into a conversation with clear checkpoints, and gives the interviewer natural places to probe deeper.
When not to use it
- Don't recite the framework's step names out loud as a checklist — use it to organize your own thinking, and skip steps the interviewer explicitly waves past.
- Don't spend more than ~5-8 minutes on requirements/estimates in a 45-minute interview — it's a means to scope the rest of the conversation, not the deliverable.
- Don't apply the full framework to a narrow, single-component question ("how would you rate-limit this endpoint") — scale the structure down.
Failure modes to call out
- Spending 20 of 45 minutes on requirements and never reaching architecture.
- Designing for a scale nobody asked for (or ignoring scale that was explicitly stated).
- Presenting one architecture with no discussion of alternatives or trade-offs.
- Not noticing when the interviewer is signaling to move on to the next step.
Alternatives & trade-offs
| Alternative | Trade-off |
|---|---|
| Jump straight to a familiar architecture | Fast to start, but risks solving the wrong problem if you skipped clarifying scale, consistency needs, or read/write ratio. |
| Answer only what's asked, step by step | Safe but can look passive — strong candidates proactively raise trade-offs the interviewer didn't ask about yet. |
| This framework: requirements → estimates → API → data model → high-level architecture → deep dive → trade-offs | Takes discipline to timebox each step, but demonstrates structured thinking and leaves time for the deep dive that actually differentiates candidates. |
Diagram
The RADIO-style sequence: each box is a checkpoint, not a rigid script.
Scroll the diagrams sideways to see all of them.
Estimation example
For a URL shortener: 100M new URLs/month ≈ 40 writes/sec average; a 100:1 read/write ratio ≈ 4,000 reads/sec average, several times that at peak. That single estimate already tells you: this is read-heavy (favor caching), writes are low-volume (don't over-engineer write throughput), and you'll want a CDN/cache in front of redirects before touching database internals.
Say this out loud in the interview
- "Before I design anything, can I confirm the read/write ratio and rough scale?"
- "Here's the API surface I'd expose — does this match what you had in mind?"
- "I'm choosing [X] here because of [trade-off]; the alternative would be [Y], which costs us [Z]."
- "Given the time we have left, which part would you like me to go deeper on?"
Practice it in a case study
Design a URL Shortener
Walk the full framework end to end on a concrete, live case study.
Done with this lesson?
Mark it complete once you've worked through the content and practice above.
Next lesson
SQL vs NoSQL
