Pattern Review

1. How to Use This Lesson

This lesson is the course compressed for review: every pattern in one line, every big decision in one sentence, and a diagnostic table that maps symptoms back to patterns. It does not replace the lessons. Each one-liner links back to its lesson, where the full walkthrough, the numbers, and the TL;DR card live.

Three ways to use it:

1. The night before an interview: read sections 2 through 5 top to bottom (about 15 minutes), then run one capstone actively.
2. During design work: use section 2 as a lookup: find your symptom, follow the link.
3. As a self-test: cover the right-hand column of any table and reconstruct it. Any row you cannot fill in is your study list.

2. Symptom → Pattern: The Diagnostic Table

Every lesson in this course opened with a system on fire, because recognizing shapes from symptoms is the skill. Here are the fires, one line each:

3. The Pattern Index

The course's sixty-plus patterns, one line each: the problem it solves, and the price you pay. Cover a column to self-test.

Module 2: Moving Data

Module 3: Storing Data

Module 4: Serving Data Fast

Module 5: Surviving Failure

Module 6: Growing Under Load

Module 7: Keeping Data Consistent

Module 8: The Entry Point

Module 9: Operating in Production

Module 10: Data-Intensive Systems

Module 11: AI-Era Systems

4. The Decision Cheat Sheet

The rulings the course's comparisons produced, one sentence each:

1. Push vs. pull (the feed): push for the many, pull for the few: the celebrity threshold is empirical.
2. SSE vs. WebSocket: if the client never needs to talk mid-stream, SSE: buy the two-way connection only when both directions are real.
3. Queue vs. pub/sub: a queue when one consumer must do the work; pub/sub when many consumers each react to the fact.
4. Cache strategy: cache-aside by default; read-through when the library fits; write-behind never for money.
5. Vertical vs. horizontal: exhaust one machine before renting two hundred.
6. 2PC vs. saga: 2PC only inside one trust boundary; sagas across boundaries; best of all, design the transaction away with ownership or a single journal.
7. Batch vs. streaming: the staleness budget decides: don't stream what batch can serve within budget.
8. Lambda vs. Kappa: one definition of truth per metric; Kappa where log retention covers the reprocessing horizon; accidental Lambda never.
9. Idempotent vs. transactional sinks: keyed upserts first; transactions where outputs must move atomically with offsets: money, ledgers.
10. Raw CDC vs. outbox: raw table streams for your own infrastructure; the outbox for events other teams consume; dual-writes never.
11. RAG vs. fine-tuning vs. long context: RAG for knowledge, fine-tuning for behavior, long context for small stable corpora: and they compose.
12. Own GPUs vs. provider APIs: API-first until volume, latency, or privacy forces the fleet: then the GPU lessons are the cost.

5. Seven Threads That Run Through Everything

Sixty-plus patterns, but far fewer underlying ideas. Reviewing these seven reviews half the course at once:

1. Skew. Hashing spreads keys, never weight. The hot shard, the hot cache key, the slow reducer, the hot partition, the hot cluster, the giant tenant, the fee account: one problem, seven appearances, and the same remedies: split, salt, pre-aggregate, dedicate, cache.
2. Same question, two authors. Dual-written search indexes, batch-vs-streaming metrics, training-vs-serving features: whenever the same logic lives in two codebases, it drifts. The cure is structural: one definition, compiled to every path.
3. The log. The WAL under the database, replication feeding replicas, event sourcing's journal, Kafka's topics, CDC's published changes, streaming checkpoints, the agent's step log: append-only history plus a position is the course's single most reused idea. Durable state, recovery by replay.
4. Budgets: staleness and guarantees, priced per question. How old may this answer be, and who audits this number? Dashboards tolerate; invoices don't. The same stream can serve both, with different machinery: pay for the guarantee only where the question demands it.
5. Idempotency under at-least-once. Networks retry, frameworks retry, agents re-decide. Every delivery is at-least-once somewhere, so every effect needs a key that makes the second attempt harmless: generated at the source, honored at the sink.
6. Ownership over agreement. The best distributed transaction is the one you designed away: one matcher owns a driver, one writer owns an account, one consumer owns a partition. Single ownership with short leases replaces locks and coordinators.
7. Fail open vs. fail closed. Availability features degrade to lesser answers; money and authorization refuse instead. In AI systems the line runs between words and hands: words may degrade, hands must not.

6. The Whiteboard Checklist

The five questions, restated as the procedure to run on any blank whiteboard:

1. Flow: who waits, and who shouldn't? (Sync request-response vs. async queues.)
2. Storage: what is truth, and what is derived? (Sources vs. read models, caches, indexes.)
3. Speed: what is read most, and how stale may it be? (Caching tiers, precomputation, budgets.)
4. Failure: for every arrow: what happens when its far side hangs, dies, or answers twice? (Timeouts, retries, idempotency, breakers, degradation.)
5. Growth: what doubles first, and what breaks when it does? (The bottleneck, the hot key, the scaling signal.)

And the three habits that frame it, from the first lesson onward:

• Numbers before boxes: run the arithmetic first; let it veto over-engineering.
• Every pattern pays its price aloud: name the cost in the same sentence as the pattern.
• Question four wins interviews: the failure walk is where seniority shows.

If any row in this lesson surprised you, its link is the study list. Then close the course with the conclusion.