System Design Interviews: A Complete Guide for 2025
How the world's best engineers approach URL shorteners, news feeds, and distributed storage problems.
AI-powered with scored feedback and specific improvement tips.
The Framework That Works
System design interviews feel open-ended by design. The interviewer wants to see your thought process, not a perfect answer. Here is the 6-step framework top candidates use:
Ask: functional requirements (what must the system do?), non-functional requirements (scale, latency, consistency), and constraints. Never start designing without this.
Back-of-envelope: QPS, storage, bandwidth. This drives architecture decisions. "100M users, 1% daily active, 5 writes/day = 57K writes/sec"
Draw the major components: clients, load balancer, app servers, DB, cache, CDN, queue. Explain data flow end-to-end.
Spend the most time here. Pick the hardest part (usually storage, consistency, or fan-out) and go deep.
Ask: what breaks first? What would you shard? Where do you add caching? How do you handle failures?
Interviewers love when you say "I chose X over Y because..." Show you know multiple options exist.
Classic Problems and Key Insights
Base-62 encoding for short codes, KV store for lookup, CDN for redirect performance. Key question: how do you handle 301 vs 302?
Fan-out on write vs fan-out on read. Push vs pull. Celebrity problem. Ranked vs chronological.
Consistent hashing for sharding, eviction policies (LRU/LFU), replication for availability.
Token bucket vs leaky bucket vs sliding window. Where to store state (Redis). Per-user vs global limits.
Trie vs inverted index. Caching popular queries. Latency budget: < 100ms end-to-end.