CHAPTER 36
The Design Playbook
How to run a system design interview or design review, for classic and AI systems
Source: PDF pp. 99–101
Core PDF content
PDF page 99What is being evaluated p. 99
| Dimension | What strong looks like |
|---|---|
| Problem exploration | Asks sharp clarifying questions, states assumptions, scopes the problem, identifies the core challenge (e.g. "this is a fan-out problem") |
| Structure and | Follows a clear framework, narrates thinking, checks in with the interviewer, adapts to hints, manages time |
communication
| High-level design | Coherent end-to-end architecture; each component justified by a requirement; clear data flow |
|---|---|
| Depth | Goes deep where it matters: data models, algorithms, failure modes, concurrency, capacity numbers |
| Trade-offs and judgement | Names alternatives and why they were rejected; states what is given up; prefers the simplest design that works |
| Scale and reliability | Estimates load, finds bottlenecks and single points of failure, plans for failure, observability and operations |
| AI-specific judgement | Chooses ML/LLM only where justified; defines metrics and evals; handles data, drift, safety, latency and cost |
A 45-minute run sheet p. 99
| Minutes | Step | Do this | Say something like |
|---|---|---|---|
| 0-5 | Clarify | Users, core features, scale, read/write ratio, latency/consistency/availability needs, what is out of scope | "Before designing, let me confirm the scope and numbers ..." |
| 5-8 | Estimate | QPS, storage, bandwidth; derive one or two design implications | "That is ~20 k reads/s, so we need caching ..." |
| 8-13 | API + data | 3-6 endpoints, main entities, access patterns, chosen store with reason | "The key access pattern is by user_id, so I will shard on that." |
| 13-23 | High-level design | Draw the happy path, number the steps, explain each box | "Request flow: 1 ... 2 ... 3 ..." |
| 23-35 | Deep dive | Pick the hardest components (let the interviewer steer); algorithms, schemas, concurrency, failure | "The interesting part is ... Options are A and B ..." |
| 35-42 | Scale and failure | Bottlenecks, hot keys, SPOFs, replication, multi-region, degradation | "If this node dies ... If traffic doubles ..." |
| 42-45 | Wrap up | Summarise decisions and trade-offs, monitoring, future work | "If requirements shift to X, I would change Y." |
- Think aloud and keep the interviewer in the loop; treat the session as collaboration. Ask "Shall I go deeper on X or move on to Y?"
- State assumptions explicitly ("assume 100 M DAU, 1 KB per record") and revisit if corrected.
- Draw first, then talk through the flow; label arrows; mark sync vs async (solid vs dashed).
- Start simple, then evolve. Present a single-server design, then scale it: it shows reasoning, not memorisation.
- Quantify with numbers and rules of thumb; end estimates with a conclusion about the design.
- Name trade-offs every time you choose: "I choose X because Y; the cost is Z; alternative W fits if ...".
Trade-off phrases that signal seniority p. 100
- "This favours availability over consistency; for this feature a few seconds of staleness is acceptable because ..."
- "We pay write amplification to get cheap reads, which matches the 100:1 read-write ratio."
- "I would start with a managed Postgres and cache; we can shard when we exceed N writes/s; here is the migration path."
- "To limit blast radius we deploy cell by cell with canaries and automated rollback."
Common mistakes p. 100
| Mistake | Better |
|---|---|
| Jumping to a solution before requirements | Spend the first 5 minutes on scope and scale |
| Buzzword soup (Kafka, Kubernetes, microservices | Add each component only to solve a stated problem |
everywhere)
| Ignoring numbers | Do the back-of-envelope; derive decisions from it |
|---|---|
| Single points of failure and no failure story | Ask "what happens when this dies?" for each box |
| Treating the DB as a magic box | Choose the store, schema, keys, indexes and sharding strategy explicitly |
| Over-engineering | Prefer the simplest design that meets requirements; evolve it |
| Silent thinking, or never checking in | Narrate; confirm direction at transitions |
| (AI) Reaching for an LLM or deep model by default | Show the baseline, the metric and why more complexity is needed |
| (AI) No evaluation or safety plan | Define offline and online metrics, a golden set, guardrails and monitoring up front |
Question bank to ask the interviewer p. 100
- Users and scale: how many users, DAU, peak QPS, growth, geographic spread? Features: MVP vs nice-to-have, mobile vs web, real-time or eventual?
- Quality: latency target, availability, consistency requirement, durability, data retention, compliance (GDPR, PCI, HIPAA)?
- Constraints: existing stack, team size, budget, build vs buy, timeline?
- (AI) Success metric: what does a good answer or prediction mean, and how will we measure it? Data: what exists, how labelled, privacy limits? Risk: cost of wrong answers, need for citations, human review? Latency and cost: per-request budget, volume, acceptable staleness?
Checklists to run through before you finish p. 101
| Classic system checklist | AI / LLM system checklist |
|---|---|
| Requirements and scale stated API and data model defined Storage choice justified; sharding key chosen Caching strategy and invalidation Async work offloaded to queues Consistency model per feature Failure modes, retries, idempotency Replication and multi-region story Security: authN/Z, encryption, abuse Observability: metrics, logs, traces, SLOs Cost and capacity headroom Evolution and migration path | Use case and success metric defined; baseline first Data sources, labels, privacy, freshness Features / retrieval design; training-serving parity Model choice: API vs self-host; size vs cost Prompting, RAG, tools, fine-tuning decision Latency budget (TTFT, throughput) and caching Evaluation: offline golden set, online metrics, A/B Guardrails: injection, PII, moderation, permissions Monitoring: quality, drift, cost, abuse, feedback loop Human-in-the-loop and fallbacks Rollout: shadow, canary, rollback Governance: audit, compliance, retention |
Review questions for this chapter have not been written and reviewed yet. The chapter text above is the full source content.
References
System Design & AI System Design: The Complete Guide — 2026 Edition, pp. 99–101; figures 69.
Tip: use ← and → keys to move between chapters.