Design a system at scale from scratch โ simulate a real interview, evaluate all 30 days of knowledge. Five real-world scenarios, a 20-item design checklist, and a scoring rubric.
Treat each scenario like a real system design interview. Start with clarifying questions, estimate scale, design incrementally. Use the interactive checklist to track your approach. Time yourself โ 45 minutes per scenario.
Requirements โ Estimation โ High-level design โ Deep Dive โ Tradeoffs. Skip any phase and interviewers notice. The order matters โ constraints drive architecture.
5 min requirements, 5 min estimation, 15 min design, 10 min deep dive, 5 min tradeoffs and evolution. Practice hitting these targets.
Explain every decision. "I'm choosing PostgreSQL because this is a 100:1 read-to-write ratio and we need strong consistency for order records." Silence loses points.
Start simple (single server), add complexity only where scale demands it. "Day 1: monolith. At 1M users: add cache. At 100M users: shard DB." Shows engineering maturity.
Check off each item as you complete it in your design. Progress is saved in your browser. Use this for every practice session.
Each scenario has realistic scale constraints. Use the notes area to sketch your approach. There are no wrong answers โ only well-justified and poorly-justified ones.
Score yourself honestly. Senior engineer bar is 3+ across all areas. Staff engineer bar is 4 in Architecture, Scalability, and Tradeoffs.
| Area | 4 โ Excellent | 3 โ Good | 2 โ Adequate | 1 โ Needs Work |
|---|---|---|---|---|
| Requirements | Covers all; proactively asks about scale, consistency, SLA | Covers basics; some scale questions | Functional only; no non-functional | Jumps straight to design |
| Architecture | Right tech for right use case; every choice justified | Reasonable choices; most justified | Some mismatches (NoSQL for ACID data) | Random or cargo-cult choices |
| Scalability | Identifies bottlenecks; solutions for each; hotspot awareness | Discusses some scaling; horizontal scaling mentioned | Basic "add more servers" only | Single-server design; no scaling plan |
| Deep Dive | Complete design of critical component; edge cases covered | Good depth on chosen component; minor gaps | Surface level; no schema or API detail | No deep dive; stays high-level only |
| Tradeoffs | 3+ explicit tradeoffs with clear reasons for each choice | 2 tradeoffs; some reasoning | 1 tradeoff; "it depends" without resolution | None mentioned; treats choices as obvious |
Memorize these. Interviewers expect you to use them for back-of-envelope estimates without looking them up.
| Operation | Latency | Throughput |
|---|---|---|
| Redis GET/SET | 0.1ms | 100K ops/sec per node |
| PostgreSQL query (indexed) | 1โ5ms | ~10K QPS/server |
| Network round-trip (same AZ) | 0.5ms | 10 Gbps |
| Network round-trip (cross-region) | 50โ150ms | varies |
| SSD random read | 0.1ms | 200K IOPS |
| HDD random read | 10ms | 100 IOPS |
| Kafka publish | 1โ5ms | 1M msg/sec per broker |
| HTTP request (LAN) | 1โ2ms | โ |
| CDN cache hit (global edge) | 5โ20ms | Tbps aggregate |
| Memory read (RAM) | 100ns | 100 GB/sec |
QPS = DAU ร actions/day รท 86,400 ร peak_factor (2-5ร). Storage = events/day ร bytes/event ร retention_days. Bandwidth = QPS ร avg_response_bytes. Cache size = QPS ร latency ร avg_object_size (Little's Law). Always round to the nearest order of magnitude.
30 days. 120+ exercises. Real-world case studies covering Slack, Netflix, Uber, Google, Twitter, and more. You've studied distributed systems theory, storage engines, consensus protocols, and observability โ and built intuition for architectural tradeoffs.