The 45-Minute System Design Framework

A system design interview is a structured conversation, not a quiz with one right answer. You're scored on how you drive it: clarifying an ambiguous problem, making reasonable estimates, producing a working design, and going deep on trade-offs. A consistent framework keeps you from spending 30 minutes on boxes and running out of time for the deep dives where senior candidates earn their level.

1The Timeline

Practise with the timer below until the phases feel natural.

2Phase by Phase

Requirements. Ask, don't assume: Who are the users? What are the core features? How many users, and how fast is it growing? Read-heavy or write-heavy? What latency is acceptable? Can we lose data? Is eventual consistency OK? Write the answers down where the interviewer can see them, and confirm scope ("I'll focus on posting and the feed, not ads or search. OK?").

Estimation. Compute only what affects decisions: does it fit in one database? Do we need a cache? How much bandwidth? State assumptions and round aggressively (see the estimation lesson).

API and data model. Define the contract before the boxes: POST /v1/posts, GET /v1/feed?cursor=. List the entities and their access patterns; choose storage from those patterns, not from habit.

High-level design. Draw the simplest design that meets every functional requirement, then walk a request through it ("the user posts: LB → post service → posts DB, then an event to the fan-out queue…"). Don't optimize yet.

Deep dives. Pick the 2–3 parts where the hard problems are (often the interviewer will choose): the hot path at scale, data partitioning, consistency, caching strategy, failure handling. For each: options → trade-offs → decision.

Wrap-up. Identify single points of failure and bottlenecks, how you'd monitor the system (key metrics and alerts), and what you'd build next.

3Driving the Conversation

• Think out loud: the interviewer scores your reasoning, not just the final diagram.
• Check in at phase boundaries: "Does this cover what you had in mind? Shall I go deeper on the feed generation?"
• Follow hints: if the interviewer asks "what happens if this cache dies?", that's where they want you to go.
• Name trade-offs explicitly: "Fan-out on write makes reads fast but celebrities' posts expensive; I'll use a hybrid."
• Don't wait for perfect information: make an assumption, say it, and move on.

4Practise on the Classic Designs

Run through the framework on each design in the System Design category: the URL shortener, rate limiter, ID generator, news feed, chat, notifications, autocomplete, video streaming, file sync, web crawler, key-value store and payment system. Do each one timed and out loud, then compare with the lesson.

Start with: URL shortener · rate limiter · news feed · chat · payment system

⚠️ Common Pitfalls

1. Jumping into boxes before requirements: you design the wrong system.
2. Over-long estimation: five minutes of arithmetic that doesn't change any decision.
3. Buzzword architecture: Kafka, Kubernetes and microservices with no reason given.
4. No deep dive: a broad, shallow design reads as mid-level.
5. Silence: drawing for minutes without explaining.
6. Ignoring the interviewer's hints to follow your rehearsed script.

📋 Quick Reference

0–5 requirements · 5–10 estimation · 10–15 API + data · 15–25 high-level · 25–40 deep dives · 40–45 wrap-up
Ask → write down → confirm scope; estimate only what changes decisions
Walk a request end to end; then options → trade-offs → decision for 2–3 hard parts
Think aloud, check in at phase boundaries, follow the interviewer's hints

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: intv_the_45_minute_framework_theory.md · generated by tools/build_lessons.py