The recurring patterns and a self-assessment

Section 1 made a claim: system design is not memorising twenty-five architectures, it is a small vocabulary of building blocks plus the judgement to choose between them. Twenty-five case studies later, this lesson is where that claim gets tested.

Here is the test. Below are five moves that appeared repeatedly across Sections 6 to 30. If they genuinely recur, then what you learned was not twenty-five architectures — it was five decisions, each faced in a different costume. The second half of the lesson turns the same lens on you: a self-assessment that tells you which of those decisions, and which building blocks, you can already teach.

Pattern 1 — Fan-out on write versus fan-out on read

The decision. When one event must reach many recipients, do you push it to all of them at write time, or assemble it for each recipient at read time?

The trade. Fan-out on write makes reads cheap and writes expensive, and it fails on the recipient with a million followers. Fan-out on read makes writes cheap and reads expensive, and it fails when the read is on a latency budget.

Where it appeared. The news feed lessons on fan-out and the hybrid give the full costing and the hybrid that real systems use. The notification system's high-level design fans notifications out to per-channel workers. The chat system's group chat lesson fans out for small groups and syncs per user for large ones. The Nearby Friends architecture pushes locations to a channel per geohash cell rather than having friends poll. The gaming leaderboard's follow-ups lesson computes friend leaderboards on read because precomputing five million friend sets is absurd write amplification. The stock exchange's market data lesson fans the order book out to thousands of subscribers and reaches for multicast because unicast fan-out is 100 GB/s.

The rule that generalises. Precompute when the fan-out is bounded and the read is hot. Assemble on read when the fan-out is unbounded or the result set is small. Use both, split on a threshold, when the distribution has a long tail — which it usually does.

Pattern 2 — Precompute versus compute on demand

The decision. Do the work in advance and store the answer, or do it when asked.

The trade. Precomputation costs storage and staleness; on-demand computation costs latency and CPU at exactly the wrong moment.

Where it appeared. The autocomplete trie lesson caches the top-k suggestions at every trie node so a lookup is a traversal with no subtree scan. The proximity service's indexing lesson builds geospatial indexes in advance because the data barely changes. The Google Maps lessons on tiles and routing pre-render map tiles and precompute routing shortcuts because a continental Dijkstra search is far too slow live. The metrics lessons on downsampling and alerting downsample and precompute rollups so a dashboard does not scan 1.3 billion points. The ad click pipeline keeps aggregates for reading and raw events for recomputing. The hotel system's search lesson maintains a denormalised search index separate from the booking database.

The rule that generalises. Precompute when the read rate is far above the write rate and staleness is tolerable. Section 19 (Nearby Friends) is the counter-example worth remembering: when the underlying data changes constantly, precomputation is unaffordable and the design must invert.

Pattern 3 — Idempotency as the real answer to exactly-once

The decision. How do you make an operation that may be delivered twice have an effect exactly once?

The trade. There is not much of one. Idempotency costs a stored key and a unique constraint, and it is the only mechanism that actually works.

Where it appeared. The building-block lessons on message queues and reliability patterns introduce the vocabulary and state that exactly-once without idempotency is mostly a lie. The notification system's reliability lesson attaches a deduplication key so a retry cannot double-notify. The message queue's delivery semantics lesson shows why the broker cannot give you exactly-once against an external side effect. Exactly-once ad click aggregation prices a double-counted window at ₹200,000 of phantom revenue. The hotel booking lesson stops a retried booking becoming two reservations. Double-payment prevention is the full treatment, including the ordering detail that makes it work under concurrency. The digital wallet's distributed correctness lesson makes every step of a cross-shard saga idempotent so retries are harmless.

The rule that generalises. Assume at-least-once delivery everywhere. Derive a key from the intention rather than the request, enforce it with a unique constraint, write it first in the transaction, and store the original response so a retry converges rather than diverges.

Pattern 4 — Sharding, and the hot key that follows it

The decision. Split data across machines by some key — and then discover that one key is far busier than the rest.

The trade. Any key that gives good ordering or locality tends to give bad distribution, and the reverse.

Where it appeared. Sharding, and what it takes away introduces sharding and what it takes away. Partitioning and replication gives the topologies. Section 7 (Design Consistent Hashing) is an entire section on distributing keys evenly, with virtual nodes existing precisely because the naive ring distributes badly. Then the hot key arrives, again and again: the celebrity in the news feed; letter-frequency imbalance in the trie shards of search autocomplete; the hot partition in the message queue; high-cardinality labels in metrics monitoring; the dominant advertiser in ad click aggregation; the shared mailbox in the email service; the single global leaderboard in the gaming leaderboard; the merchant wallet in the digital wallet.

The rule that generalises. Pick the highest-cardinality key that preserves the ordering you need. Expect a hot key anyway. The repairs are always the same three: salt the key and merge on read, pre-aggregate before the key is applied, or give the hot key dedicated capacity.

Pattern 5 — Splitting the read path from the write path

The decision. Serve reads and writes from the same components, or design two systems joined by an asynchronous stream.

The trade. One path is simpler and forces both workloads to share a storage engine, a consistency model, and a failure domain. Two paths cost duplication and a replication lag.

Where it appeared. Section 24 (Design a Hotel Reservation System) is the clearest case: 23,000 searches per second against 23 bookings per second, so the search path is cached and denormalised while the booking path is transactional. The ad click pipeline separates ingest from query. The object store's architecture makes the metadata-versus-data split the entire architecture. The digital wallet's event-sourcing lesson splits commands from queries explicitly, and states the rule that a debit is authorised against command state and never against the read model. The YouTube lessons on upload and streaming build the upload path and the streaming path as different systems. The email service's storage design separates hot metadata from cold bodies. Section 22 (Design a Metrics Monitoring and Alerting System) separates a 2-million-per-second write path from a few-hundred-per-second read path.

The rule that generalises. When the read-to-write ratio is far from one to one, or when the two paths need different consistency guarantees, split them and join them with an event stream. Then say out loud what the resulting staleness window means to a user.

Five more, in a sentence each

The append-only log as the source of truth. Key-value storage engines; the message queue's queue versus log and storage on disk; the ad click pipeline; wallet event sourcing; stock exchange reliability. Sequential writes are fast, immutable history is auditable, and derived state can always be rebuilt.

Cache the hot set, and pay for it. Caching; caching strategies; the URL shortener's read path; news feed storage and caching; proximity service serving. Every cache brings staleness, invalidation, and the thundering herd along with it.

Push work off the request path. URL shortener follow-ups; the notification system's high-level design; YouTube's upload path; email delivery reliability; payment consistency across services. If the user does not need the result, it belongs behind a queue.

Independent recomputation as the correctness check. Key-value failure handling; ad click reconciliation; payment reconciliation; wallet verification; stock exchange reliability. Two implementations over the same input fail differently, which is what makes their agreement evidence.

Quorums and replication for durability. Partitioning and replication; key-value quorums; message queue replication; object storage durability; wallet distributed correctness. How many copies, how many must acknowledge, and what you give up when one is unreachable.

A self-assessment

Knowing the patterns is one thing; knowing which ones you could defend under questioning is another. Re-reading sixty hours of material is not a study plan. Finding your own gaps and reading only those is. The rest of this lesson is the instrument for that.

Work through the checklists below and mark each item honestly as one of three states: I can explain this to someone else, I recognise it but could not teach it, or I could not explain this. Only the third and second states need work, and the second usually needs one worked example rather than a re-read.

Building blocks — Section 5

The patterns — from the first half of this lesson

The procedure — Sections 3 and 4

Turning the assessment into a plan

Count your third-state items. Then:

• Fewer than five. You are ready to practise rather than to read. Go to Practising without an interviewer.
• Five to fifteen. Re-read exactly those topics, then design one system that uses each — not the lesson's system, a different one. If quorums are shaky, design a distributed configuration store; if fan-out is shaky, design a live sports commentary feed.
• More than fifteen, concentrated in one part. That part was probably read passively. Redo two of its case studies under the 45-minute rule from the introduction, on paper, before reading.
• More than fifteen, spread evenly. Go back to Section 5 and Part II (Sections 6–11). The foundations are thin, and no amount of case-study reading compensates for that.