How to Structure a 45-Minute System Design Interview

easy

Scale: N/A — framework FAANG, All Tier-1 tech

FrameworkInterview Prep

A 45-minute system design interview is tight. The difference between strong and weak candidates is rarely technical knowledge — it's structure. Strong candidates drive the session: requirements, estimation, high-level design, deep dive, trade-offs.

ScaleN/A — framework

Key Concepts

1. Phase 1 — Requirements (5 min). Functional: top 3-5 user stories. Non-functional with numbers: scale (DAU, QPS), latency targets (p50, p99), availability (99.9 = 8.76h/yr; 99.99 = 52 min/yr; 99.999 = 5 min/yr), consistency model per data class, durability (RPO/RTO), geographic scope, compliance (GDPR, PCI, HIPAA), cost ceiling. State what's out of scope.

1. Phase 1 — Requirements (5 min).

2. Phase 2 — Estimation (5 min). DAU → activity → writes/s, reads/s, peak factor. Storage/year with replication. Bandwidth (egress dominated by media). Derives: shard count, cache size, fleet size. Round to one significant digit.

2. Phase 2 — Estimation (5 min).

3. Phase 3 — High-level design (15 min). Draw boxes: client → LB → API → services → DB / cache / queue / CDN. Walk through 1-2 main flows end-to-end. Pick technologies and justify each choice ('Cassandra for write throughput, eventual consistency on derived views'). Identify the dominant cost.

3. Phase 3 — High-level design (15 min).

4. Phase 4 — Deep dive (15 min). Interviewer steers. Common targets: data model + sharding key, hot path, consistency model, a specific subsystem. Show 2-3 alternatives, commit to one with reasoning. Address one failure mode explicitly. This is where senior signal lives — discussing consequences, not just listing choices.

4. Phase 4 — Deep dive (15 min).

5. Phase 5 — Wrap (5 min). Bottlenecks now. Trade-offs and why. What you'd build next (monitoring, ramp plan, capacity model). Self-assess: 'The weakest part is X; in a follow-up I'd Y.' Senior+ signals: talking trade-offs constantly, quantifying ('50K writes/s' not 'a lot'), acknowledging what you don't know, bringing up operability.

5. Phase 5 — Wrap (5 min).

Phase 1 — Requirements (5 min)

Functional:
• Top 3-5 user stories.
• Inputs and outputs.
• Explicitly out-of-scope items.

Non-functional (with numbers):
• Scale: users, DAU, QPS read/write, data size.
• Latency: p50, p99 for the hot path.
• Availability: 99.9 (8.76h/yr), 99.99 (52 min/yr), 99.999 (5 min/yr).
• Consistency: strong, eventual, causal — per data class.
• Durability: can a write be lost?
• Geography: single region, multi-region, edge.
• Compliance: PII, GDPR, PCI, regional residency.
• Cost ceiling or SLO budget.

Phase 2 — Estimation (5 min)

DAU → activity → writes/s, reads/s, peak factor.
Storage/year with replication.
Bandwidth (egress dominated by media).
Derives: shard count, cache size, fleet size.
Round to one significant digit. Precision is fake confidence.

Phase 3 — High-Level Design (15 min)

Draw boxes: client → LB → API → services → DB/cache/queue/CDN.
Walk through 1-2 main flows end-to-end.
Pick technologies, explain why: 'Cassandra for high write throughput.'
Identify dominant cost: 'Read-side caching + CDN egress is 80% of cost.'
Sketch async paths separately (Kafka, workers, scheduled jobs).

Phase 4 — Deep Dive (15 min)

Interviewer will hint where.
Common targets: data model + sharding key, hot path, consistency, specific subsystem.
Show 2-3 alternatives, commit to one with reasoning.
Address at least one failure mode explicitly.
Senior signal: discussing the consequences of design choices, not just listing them.

Phase 5 — Wrap (5 min)

Bottlenecks now.
Trade-offs and why.
What you'd build next (monitoring, ramp plan, capacity model).
Self-assess: 'The weakest part is X; in a follow-up I'd Y.'

Senior+ signals

Talk about trade-offs constantly, not just choices.

Connect design to business: 'We picked AP because the user never sees a 500.'

Numbers, not adjectives. '50K writes/s' not 'a lot'.

Acknowledge what you don't know and how you'd find out.

Bring up operability: deploy, observability, on-call.

Reference real systems and what they do (Kafka, Spanner, etc).

Comfortable saying 'I'd consult with the SREs on capacity planning.'

Common mistakes

Jumping to architecture before clarifying requirements.

Picking buzzword tech without justification.

Ignoring failures (network partition, node death).

Vague answers: 'we'll cache it' — what, where, how invalidated?

No data model.

Running out of time on diagram polish; deep dive matters more.

Saying 'I'd just use X' for everything; sounds like cargo-culting.