Minutes 0–5 — Clarify requirements
Functional requirements (what does it do), non-functional (QPS, latency, consistency), and out-of-scope. Write them on the board. Ambiguity ignored here kills you in minute 30.
TL;DR
A system design interview follows a predictable shape: requirements, API, storage, traffic, bottlenecks, deep dives. The candidates who pass aren't the ones who know every architecture — they're the ones who talk tradeoffs out loud and budget their time.
Functional requirements (what does it do), non-functional (QPS, latency, consistency), and out-of-scope. Write them on the board. Ambiguity ignored here kills you in minute 30.
Back-of-envelope: requests/sec, storage/year, read/write ratio. You don't need precision — you need an order-of-magnitude anchor for every later decision.
Client → LB → service → DB. Draw it. Name your components. Explicitly say 'I'd use X because Y' for each edge. Silent drawing loses points.
Interviewer picks a component. You deep-dive: schema, indexing, caching, sharding, replication. Narrate the tradeoff you're making and what breaks if you pick the other option.
How do you detect failure, what's the replication strategy, what's the rollout plan, what's unresolved. Naming what you haven't solved is a senior-level signal.
Book a 45-minute system design mock with a transcript. Included in the $19/mo subscription.