System Design Method
- Run the 7-step design method: requirements → capacity → API → data model → high-level design → deep dives → trade-offs
- Estimate QPS, storage, and bandwidth from user counts using round numbers
- Design a pastebin end-to-end and defend each choice against an alternative
- Turn every component choice into an explicit trade-off sentence
- Recognize the standard moves: LB + stateless replicas, cache, queue, replicate, partition
| Spaced-rep warm-up: due flashcards (Days 43–47) | 10 min |
| ELI5 + tech read: the seven steps | 15 min |
| Guided: pastebin walkthrough + estimation gym | 45 min |
| Practice: solo image-host design (timed) | 25 min |
| Project: method template + cheat sheet | 15 min |
| Quiz + flashcards | 10 min |
Builds on: Day 46 — Distributed systems vocabulary · Day 47 — Caching & queues — the standard moves · Day 38 — Indexes & database internals
Watch an architect handle a client who says "design me a house." The amateur starts sketching bedrooms immediately. The professional asks questions first: How many people? Do you cook? What is the budget? (requirements). Then they do envelope math on a napkin — four people, three bedrooms, roughly 200 square meters, which rules out this plot and that budget (capacity estimation). Only then do they draw: first the doors and windows the family will actually touch (the API), then the room list (the data model), then the floor plan showing how rooms connect (high-level design). Finally they zoom into the two rooms that are genuinely hard — the kitchen plumbing, the load-bearing wall (deep dives) — and present honestly: "a bigger kitchen means a smaller garage; here is why I chose the kitchen" (trade-offs).
System design interviews — and real architecture work — reward exactly this rehearsed order. The order is the skill: requirements before boxes, numbers before choices, hard parts last so you spend depth where it matters. Skip a step and you are the amateur sketching bedrooms for a family you never met.
The AI-system-design round is now standard in AI engineer and FDE interviews (Day 160 is a full day on it), and it is this method applied to LLM systems: "design a support copilot" is requirements → capacity (tokens, not just QPS) → API → data model (vectors + rows) → design → deep dives on retrieval and cost. In the field, the same method is how you turn a customer's "we want an assistant" into a proposal (Day 165) — asking the requirements questions IS the discovery meeting. Engineers who estimate out loud with round numbers earn trust in rooms where hand-waving loses deals.
The architect's rehearsal — six moves, in order, for any system
step 1 / 6The method exists to stop you from doing the natural thing: jumping straight to technology. Move 1 — REQUIREMENTS. Who uses it? What must it do? What must it NOT do? Worked example: a pastebin.
Guided practice
Design pastebin with the method — full walkthrough
30 minWork through all seven steps on paper or in pastebin_design.md, timing each step. Do NOT read ahead to a solution — the rehearsal is the point.
- Requirements (5 min): write 4 functional (create paste → short URL; read by URL; optional expiry; size limit 1 MB) and 4 non-functional (10M pastes/month; read-heavy; p99 read < 200 ms; pastes immutable).
- Capacity (5 min): compute write QPS, read QPS at 10:1, storage/year at 10 KB average. Round aggressively; write the arithmetic down.
- API (3 min): three endpoints with methods, paths, request/response shapes. Note which are idempotent (Day 46).
- Data model (4 min): the pastes table: id (base62 key), content, created_at, expires_at. Which column needs an index and why?
- High-level (5 min): ASCII diagram — client → LB → 2 API replicas → cache → DB (leader + follower). Draw read and write paths as separate arrows.
- Deep dive (5 min): ID generation. Compare: (a) random 8-char base62 with collision check-and-retry; (b) auto-increment counter encoded base62. For each: predictability, coordination cost, collision math (62⁸ ≈ 2×10¹⁴ keys — at 10⁷ pastes, collision odds per insert?).
- Trade-offs (3 min): write three sentences of the form "I chose X over Y, accepting Z."
The estimation gym
15 minRound-number drills — do them in your head first, then check with the starter script. Speed matters more than precision; get within 2× and move on.
- 50M DAU, each making 20 requests/day. Average QPS? Peak (×3)?
- Each request logs 500 bytes. Log volume per day? Per year?
- A tweet is ~300 bytes of text + metadata. Storage for 500M tweets/day for 5 years?
- Your LLM feature: 10k users/day, 5 conversations each, 8 calls per conversation, 2,000 tokens per call. Tokens/day? At $3 per million tokens, cost/day?
- Write your own cheat-sheet constants at the bottom: seconds/day ≈ 10⁵, KB→GB is 10⁶, "million per day ≈ 12/s".
On your own
Solo design: an image-hosting service
25 minRun the full method, alone and timed (25 min), on: "design an image-hosting service" (upload an image → get a link; 1M uploads/day; average 2 MB; read-heavy 20:1; images immutable).
Deliverable: image_host_design.md with all seven sections. Requirements you must discover yourself: where do big binary blobs live (hint: NOT in database rows — object storage + DB metadata is the standard split), and what serves the read traffic (hint: immutable + read-heavy is the perfect CDN/cache story).
Hints (only after finishing): storage is ~2 TB/day — this changes which component dominates the design; the deep dive worth doing is thumbnail generation, which is slow work arriving in bursts… which is exactly what Day 47's queues are for.
Your design method template + cheat sheet
Create two durable artifacts in your practice repo. (1) design_method.md: the seven steps as a reusable template — each step gets its timebox, the questions to ask, and a "standard moves" list (LB + stateless replicas, cache-aside, queue + workers, replicate for reads, partition for writes, index for lookups) with a one-line "reach for this when…" per move. (2) estimation_cheatsheet.md: your constants (seconds/day, powers of ten, base62 keyspace, bytes per char/int/UUID), the QPS-from-DAU recipe, the storage recipe, and — because you are an AI engineer — the token-cost recipe from the estimation gym. Tomorrow you will run this exact template against the URL shortener, and on Day 160 against three AI systems; make it something future-you can execute under interview pressure.
Common mistakes & misconceptions
- Drawing boxes before asking questions. Requirements change everything — a pastebin for 1k users and one for 100M users share a name, not a design. Interviewers dock the skipped step, not the wrong QPS.
- Estimating to three significant figures. 86,400 is 10⁵; 4.63 writes/s is "about 5." Precision theater wastes time and signals inexperience — round numbers, stated as round.
- Designing for read QPS when write QPS is the constraint (or vice versa). Always split the two; the ratio picks between replication (read-heavy) and partitioning (write-heavy).
- Adding components without a number that justifies them. "We will add Kafka" — for 4 writes/s? Every box must be paid for by a requirement or an estimate.
- Deep-diving the easy part. Ten minutes on the pastes table, zero on ID collisions or expiry. Spend depth where the difficulty is — that is the differentiating step.
- Presenting choices without their costs. "We use eventual consistency" is half a sentence. Finish it: "…accepting up to ~1 s stale reads, acceptable because pastes are immutable."
Q1. A service gets 2M writes/day. Roughly what average write QPS should you design around?
Q2. Your design is read-heavy 50:1 and items are immutable after creation. Which pair of moves does this profile practically beg for?
Q3. In the method, why do deep dives come AFTER the high-level design rather than first?
Go deeper — curated resources
- Back-of-the-envelope numbers every engineer should know — Jeff Dean's classic latency table (L1 ~0.5 ns, RAM ~100 ns, SSD ~100 µs, same-DC round trip ~0.5 ms, cross-continent ~150 ms). Find a current version and staple it to your cheat sheet — Day 43's measurements gave you the network rows empirically.
- CMU 15-445 / MIT 6.824 as the long game ↗ — The two university courses behind this week. Not for now — bookmark for the months after Day 180.
- Pastebin design complete with all seven sections and shown arithmetic
- Estimation gym answers within 2× before checking
- Timed image-host design done solo in ≤ 25 min
- Template + cheat sheet committed for reuse tomorrow
- Quiz ≥ 2/3
← Back: Every step reuses this week: the API step is Day 41/45, the data-model step is Days 36–38, the standard moves are Day 46 (replicate, partition, stateless) and Day 47 (cache, queue). The method just sequences what you already know.
Forward →: Tomorrow you run this template for real: design THEN build the URL shortener. Day 160 is this method under AI constraints — token budgets join QPS in the capacity envelope, exactly like the estimation gym's question 4 — and Day 165 turns the same skeleton into customer-facing proposals.
Unlocks: D49 Week 7 Checkpoint: Design & Build a URL Shortener · D160 AI System Design · D164 Ambiguity → Requirements