The 45-Minute Interview Framework

System design interviews are open-ended by design. Structure is what keeps you from rambling - this four-step arc works for any question, from URL shortener to global payment system.

1Understand the problem & scope it

5-10 min
  • ▸Ask clarifying questions before designing anything. Who are the users? What are the top 3 features? Mobile, web, or both?
  • ▸Split requirements into functional (what it does) and non-functional (scale, latency, availability, consistency).
  • ▸Explicitly cut scope: "I'll focus on posting and the feed; I'll skip ads and DMs unless you want them."
  • ▸Get numbers: DAU, read:write ratio, data size, growth. If the interviewer won't give them, propose reasonable ones.

"Before I design, let me make sure I understand the problem. Are we optimizing for read-heavy traffic? What scale are we targeting - millions or billions of users?"

2Back-of-envelope estimation

3-5 min
  • ▸Compute QPS (average and peak), storage per year, and bandwidth. Round aggressively - 86,400 seconds/day ≈ 100K.
  • ▸Use the results to justify decisions: 20K QPS means a single Postgres box won't cut it; 500 TB/year points at object storage.
  • ▸Estimate cache size with the 80/20 rule: 20% of objects generate 80% of reads.
  • ▸Don't over-invest here. Get the order of magnitude and move on.

"10M DAU x 10 reads/day is 100M reads/day, roughly 1,200 QPS average, call it 2,500 at peak. That's comfortably within a cached read path but too hot for a single unindexed table."

3High-level design

10-15 min
  • ▸Draw the boxes: client → DNS/CDN → load balancer → stateless app servers → cache → database → async workers/queues.
  • ▸Define the core APIs first (3-5 endpoints) - they anchor the whole diagram.
  • ▸Sketch the data model: main entities, keys, and which store they live in (SQL vs NoSQL vs blob).
  • ▸Walk through the two critical flows end to end: the main write path and the main read path.
  • ▸Keep it simple at this stage. Buy-in on the skeleton before adding muscle.

"Here's my starting skeleton. Writes go through the API to the primary DB and fan out async via a queue; reads hit cache first. Shall I deep-dive into the fan-out service or the storage layer?"

4Deep dives & wrap-up

10-15 min
  • ▸Let the interviewer steer, but proactively attack your own bottlenecks: hot partitions, thundering herds, single points of failure.
  • ▸For each problem, present 2 options with tradeoffs, then commit to one with a reason. That's the senior signal.
  • ▸Cover the reliability story: replication, failover, monitoring, and how the system degrades under partial failure.
  • ▸Close with a summary: what you built, its known limits, and what you'd do next with more time.

"The celebrity problem breaks pure fan-out-on-write. I'd go hybrid: precompute feeds for normal users, but pull celebrity posts at read time and merge. It costs read latency but caps write amplification."

Do

  • ✓ Drive the interview - you own the whiteboard and the agenda
  • ✓ State assumptions out loud and write them down
  • ✓ Quantify everything: QPS, storage, latency budgets
  • ✓ Present tradeoffs in pairs, then decide - never present a choice without making it
  • ✓ Tie every component back to a requirement
  • ✓ Leave 2-3 minutes to summarize and list future improvements

Don't

  • ✗ Jumping straight into the architecture without clarifying requirements
  • ✗ Designing for 1B users when the interviewer said 100K - or ignoring scale entirely
  • ✗ Naming technologies ("I'd use Kafka") without saying why or what tradeoff you're accepting
  • ✗ Staying silent while thinking - narrate your reasoning
  • ✗ Treating the interviewer as an examiner instead of a collaborator - check in after each phase
  • ✗ Over-engineering: microservices, multi-region, and exactly-once semantics for an MVP question

Ready to apply it? Practice against the case studies or warm up your estimation with the calculator.