The 45-Minute System Design Interview · System Design

Rule: say the phase name out loud when you enter it. Interviewers grade on structure.

Time budget#

Phase	Minutes	Output on the board
1. Requirements & scope	5-7	Functional list (3-5), non-functional list (3-5), explicit out-of-scope
2. Estimates	3-5	DAU, QPS (avg/peak), storage/yr, bandwidth; read:write ratio
3. API + data model	5	3-5 endpoints, 2-4 tables/keys with primary + one index
4. High-level design	10	Boxes and arrows: client → DNS/CDN → LB → gateway → services → cache → DB → queue → workers
5. Deep dives	10-15	2-3 hard parts chosen with the interviewer; trade-off tables out loud
6. Scale, failure, ops	5	Bottlenecks, 10x plan, SPOFs, observability
7. Summary	2	Restate design, trade-offs made, what you'd do next

Rule: say the phase name out loud when you enter it. Interviewers grade on structure.

"Let me make sure I understand the problem and scope it before I draw anything."
"Who are the users and what are the top 3 things they must be able to do?"
"What's out of scope today? I'll assume [auth / payments / analytics] exist unless you want them."
"Scale: roughly how many daily active users and what's the read-to-write ratio?"
"Non-functional priorities: is this latency-sensitive, availability-sensitive, or consistency-sensitive? I'll pick a target like p99 under 200 ms and 99.99% availability."
"Let me do quick numbers: DAU × actions/day ÷ 86,400 gives QPS; I'll size storage over 5 years."
"I'll sketch the API and the core data model, then the high-level architecture."
"Then I'd like to go deep on the two hardest parts; tell me which ones matter most to you."
"I'll call out trade-offs as I go and flag anything I'm assuming."
"Finally I'll cover scaling to 10x, failure modes, and how we'd operate it."

Functional: core actions? Read vs write heavy? Real-time or eventual? Mobile and web? Multi-region/global?
Scale: DAU/MAU, peak multiplier (2-5x), object sizes, retention period.
Consistency: "Is it acceptable if a user sees a 2-second-old view?" (almost always yes outside money/inventory).
Availability: "Would you rather be down or wrong during a partition?"
Constraints: existing stack, budget, team size, compliance (PII, GDPR, PCI).
Scope cuts: "Can I treat search / recommendations / analytics as separate systems?"

Say it, write it, move on: "Assume 10M DAU, 10 reads per write, 1 KB per record, 5-year retention."
Prefer round numbers: 86,400 s/day ≈ 10^5; 1M DAU × 10 req/day ≈ 115 QPS; peak = 3x average.
Always name the target: "p99 < 300 ms," "99.99%," "publish-to-visible < 5 s," not "fast" or "reliable."

Draw left to right: client → DNS → CDN → LB → API gateway → stateless services → cache → DB (primary + replicas) → queue → async workers → object storage.
Every box you draw gets a one-sentence justification and a named technology (Redis, Postgres, Kafka, S3, Nginx/Envoy, Cassandra, Elasticsearch).
Every arrow gets a protocol/pattern word (REST, gRPC, pub/sub, CDC, presigned URL, WebSocket).
Offer the trade-off before being asked: "Fan-out on write gives fast reads at the cost of celebrity writes; I'd go hybrid."
Check in every ~5 minutes: "Does this direction work for you, or do you want me to go deeper on X?"
When stuck: go back to the numbers; the bottleneck tells you what to design next.

Clients and entry (DNS, CDN, LB, gateway with auth + rate limiting).
Services (stateless, horizontally scaled; name the boundaries).
Data: primary DB with replication noted; cache with strategy noted; object storage for blobs.
Async: queue/stream with producers and consumers labeled; DLQ.
One ID generator or coordinator if relevant (Snowflake, Zookeeper/etcd).
Observability sidebar: metrics, logs, traces, alerts on SLOs.

Recompute QPS and storage out loud; find the first thing that breaks.
App tier: more stateless instances behind the LB (X-axis).
Reads: higher cache hit ratio, more read replicas, CDN for anything static or cacheable.
Writes: partition/shard by the natural key (user_id, conversation_id); Kafka to absorb bursts; batch writes.
Hot keys/celebrities: hybrid fan-out, key salting, local caches, replicate hot keys.
Cross-region: active-passive first; active-active only when the data model tolerates conflicts.
Cost: tiered storage, TTLs, compression, right-sized instances; say what you'd measure before spending.

"We built X for N users at Q QPS. Core path is A → B → C."
"Key decisions: [store choice] because [access pattern]; [fan-out strategy] because [ratio]; [consistency model] because [requirement]."
"Risks and next steps: [hot shard / provider dependency / cache stampede], which I'd mitigate with [concrete fix]; I'd instrument [SLI] first."
"If we had more time I'd dig into [the deep dive we skipped]."