HLD Lab · System Design Prep

§◇ · YOUR DESK

Today

understood–

designed–

re-designs due–

journal answered–

cards to clear–

Due for re-design

§00 · THE FULL MAP — SYSTEM DESIGN

The HLD atlas — every set, one table

System design rounds grade whether you can drive: name the trade-offs before being asked, quantify with estimation, and go deep on the one hard sub-problem the interviewer signals. Sets H0–H5 are the building blocks; H6 turns them into a repeatable method; H7+ are the famous questions, each an application of blocks you already own.

Set	Topic	The skill it builds	Anchor questions	Done
H0	Vocabulary & the numbers	latency table, availability nines, QPS/storage arithmetic	estimation drills	—
H1	The web tier	DNS, L4/L7 load balancers, CDN, stateless services, autoscaling	"what happens when you type a URL", senior edition	—
H2	Storage engines	B-tree vs LSM, indexes, ACID, SQL vs NoSQL families — when which	schema-choice drills	—
H3	Scaling data	replication, quorums, sharding, consistent hashing, CAP → PACELC	"your database is hot — now what"	—
H4	Caching	layers, cache-aside vs write-through/back, invalidation, thundering herd	design a distributed cache	—
H5	Async & queues	queues vs pub/sub, the Kafka mental model, delivery semantics, outbox, backpressure	design a notification system	—
H6	The script + first designs	the 45-minute timeboxed method, end to end	URL shortener · Pastebin · distributed rate limiter	—
H7	Read-heavy classics	fanout on write vs read, precompute vs on-demand	news feed · autocomplete · YouTube · web crawler	—
H8	Real-time classics	websockets, presence, delivery receipts, ordering	WhatsApp · live comments	—
H9	Geo & matching	geohash / quadtree indexes, supply–demand matching	Uber · food delivery	—
H10	Money & correctness	idempotency keys, ledgers, sagas, inventory under contention	payment system · wallet · flash sale	—
H11	Infra as the question	build the building blocks themselves	KV store (Dynamo-style) · message queue · blob store · metrics	—
H12	Advanced glue	distributed locks, leader election, consensus at concept level, clocks, bloom/HLL	deep-dive ammunition	—

§★ · THE SYSTEM-DESIGN HOUR

The HLD interview script — timeboxed

Requirements (5 min). Three to five functional requirements — then the non-functional ones that DECIDE the design: scale (how many users? reads vs writes?), latency, and the consistency-vs-availability preference. Name what’s out of scope, out loud.
Estimation (3 min) — only where it changes a decision. DAU → QPS (÷ ~10⁵ per day, × 2–3 for peak), storage per year, bandwidth. One or two numbers, not a spreadsheet.
API sketch (3 min). Three to five endpoints, request/response shapes only.
Data model (5 min). The main tables/collections, the access patterns they serve, the sharding key candidate.
High-level diagram (10 min). Client → LB → services → cache → store → queue. Then walk one request end-to-end through it — the walk catches what the boxes hide.
Deep dives (10–15 min). The one or two genuinely hard sub-problems, chosen from the interviewer’s signals: fanout, hot keys, ordering, idempotency. This is where senior is decided.
Wrap (5 min). Bottlenecks, single points of failure, monitoring, how the design evolves at 10×.

The senior differentiator

You VOLUNTEER trade-offs with reasons — “choosing availability over consistency here, because a stale like-count is harmless” — instead of being dragged to them. Every claim gets a because; every choice names the alternative it beat.

§★ · MEMORIZE THE EXPONENTS, NOT THE DIGITS

Latency numbers & estimation arithmetic

Every estimation in every design leans on a dozen physical facts. These are rounded on purpose — orders of magnitude are what decide designs:

Operation	Cost	The design consequence
L1 cache reference	~1 ns	CPU work is never your bottleneck in these rounds
Main-memory reference	~100 ns	CPU work is never your bottleneck in these rounds
Read 1 MB from memory	~0.25 ms	in-memory caches feel free
SSD random read	~0.1 ms	disk is 100–1000× memory — hence caching exists
Read 1 MB from SSD	~1 ms	disk is 100–1000× memory — hence caching exists
Spinning-disk seek	~10 ms	why sequential logs beat random writes (LSM, Kafka)
Round trip, same datacenter	~0.5 ms	a few internal hops per request are fine
Round trip, cross-continent	~100–150 ms	geo-replication and CDNs are latency decisions, not luxuries

The QPS recipe: a day is ~86,400 s ≈ 10⁵. So events per day ÷ 10⁵ ≈ average QPS, × 2–3 for peak. 100M DAU × 10 reads each = 10⁹/day ≈ 10,000 QPS average, ~30k peak. Storage: items/day × bytes/item × 365 × replication factor. Say the arithmetic out loud — showing the ÷10⁵ trick is itself a signal.

§★ · A REQUIREMENT WALKS IN

The signal router — requirement → component

1. Reads vastly outnumber writes → cache + read replicas; ask how stale is acceptable

2. Traffic is spiky, or a downstream is slow → queue as a buffer; consumers scale independently

3. Data no longer fits one machine → shard — and consistent hashing so growth doesn’t reshuffle everything

4. A machine dying must not lose data → replicate; then CHOOSE: wait for replicas (consistent) or don’t (available)

5. Money moves, or retries exist → idempotency keys + an append-only ledger

6. One event, many interested parties → pub/sub; decide fanout-on-write vs fanout-on-read

7. “Nearby / within radius” queries → geo index (geohash / quadtree), not a WHERE clause

8. Celebrity / hot-key skew → cache the hot set + split the key + jittered expiry

9. Order matters per user/entity → partition by that entity — order within a partition is free

10. Huge counts / uniques, approximately fine → sharded counters, HyperLogLog — exactness is a cost decision

§∞ · RUN THE PROTOCOL ON EACH

Practice ladder

Protocol per design

Read only the requirements → 30-minute attempt on paper (diagram + key decisions) → open the staged model answer one fold at a time → journal (Requirements / Choices / Trade-offs / What I missed) → re-design blank on day +3 and day +10.

§∞ · REQUIREMENT → DESIGN MOVE

Signal drill — flashcards

Each card is a phrase from a real requirements conversation; answer with the design move it should trigger. The deck grows with every set; misses are saved and lead the next shuffle.

signal → move— left

signal

// This lab grows one set at a time — feed it via DESIGN-PROMPT.md and each set arrives with staged model answers, diagrams, ladder entries, flashcards, and journal drills.