System design round playbook
Core details
Recommended spine (adjust timing):
| Phase | Minutes (indicative) | Output |
|---|---|---|
| Requirements | 3–5 | user personas, queries, non-goals |
| Capacity sketch | 5–7 | rough QPS/storage/SLA |
| API | 5 | verbs + idempotency cues |
| Data model | 7–10 | tables/keys + access paths |
| Architecture | 10–15 | services + data flow |
| Deep dive | remainder | pick 1–2 (search, feed, cache, consistency) |
Always draw read path and write path separately once data appears.
Understanding
Interviewers penalize jumping to shards before clarifying queries—constraints drive partitioning, not aspiration. Skeleton quality beats decorative boxes: ambiguous API contracts propagate hidden scaling traps later.
Design is iterative—explicitly revisit earlier assumptions after capacity exercise (“this invalidates naive single-region assumption”).
Senior understanding
| Anti-pattern | Fix |
|---|---|
| Tech salad (Kafka+Cassandra…) | quantify query pressure first |
| Missing failure story | degrade path + drills |
| Omitting observability | SLO sketch + paging philosophy |
| Skipping rollout/migration | dual-write phased story |
Tie costing to capacity drivers you already drew (fan-out peaks, replication, storage churn)—ballpark tiers, not false precision.
Diagram
Loading diagram…
See also
Spotted something unclear or wrong on this page?