Pattern Review

1. How to Use This Lesson

This lesson provides a compact course review through one-line pattern summaries, major decisions, and a diagnostic table that maps symptoms to patterns. It does not replace the complete lessons; each summary links to the detailed walkthrough, calculations, trade-offs, and final reference card.

Three ways to use it:

1. The night before an interview: read sections 2 through 5 in approximately 15 minutes, then complete one capstone actively.
2. During design work: use section 2 as a lookup by finding the observed symptom and opening the linked pattern.
3. As a self-test: hide the right-hand column of any table and reconstruct it from memory; review every linked lesson whose row you cannot complete accurately.

2. Symptom → Pattern: The Diagnostic Table

Every lesson began with a failing system because diagnosis requires mapping observed symptoms to known design problems; the following table summarizes those mappings.

3. The Pattern Index

The following index summarizes more than sixty patterns; each row identifies the problem a pattern solves and the operational or correctness cost it introduces. Hide one column to test your recall.

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 course's comparisons produced the following concise decision rules:

1. Push vs. pull (the feed): push for most accounts and pull for high-follower accounts, using an empirically measured threshold.
2. SSE vs. WebSocket: use SSE when clients do not send messages during the stream, and maintain two-way connections only when both directions are required.
3. Queue vs. pub/sub: use a queue when one consumer performs each job, and pub/sub when independent consumers react to the same event.
4. Cache strategy: begin with cache-aside, use read-through when its library model fits, and avoid write-behind for financial data.
5. Vertical vs. horizontal: use one sufficiently large machine before accepting the operational costs of a large distributed fleet.
6. 2PC vs. saga: use 2PC only within one trust boundary and sagas across boundaries; prefer ownership or one journal when either can remove the distributed transaction.
7. Batch vs. streaming: let the staleness budget decide, and retain batch when it can meet the required deadline.
8. Lambda vs. Kappa: maintain one metric definition, and use Kappa when log retention covers the reprocessing horizon; avoid separate pipelines without reconciliation.
9. Idempotent vs. transactional sinks: begin with keyed upserts, then use transactions when outputs and offsets must advance atomically for financial records.
10. Raw CDC vs. outbox: use raw table streams for internally owned infrastructure and outbox events for consumers in other teams; avoid dual-writes.
11. RAG vs. fine-tuning vs. long context: use RAG for knowledge, fine-tuning for behavior, and long context for small stable corpora; these approaches can be combined.
12. Own GPUs vs. provider APIs: begin with provider APIs until sustained volume, latency, or privacy requirements justify operating a GPU fleet.

5. Seven Threads That Run Through Everything

More than sixty patterns derive from a smaller set of recurring principles; reviewing these seven principles covers much of the course's reasoning.

1. Skew. Hashing distributes keys but not their weights; this issue appears as hot shards, cache keys, reducers, partitions, clusters, tenants, and fee accounts. Common remedies are splitting, salting, preaggregation, dedicated capacity, and caching.
2. Same question, two authors. Two implementations of the same logic eventually diverge; dual-written search indexes, separate batch and streaming metrics, and inconsistent training and serving features share this cause. Define logic once and generate or reuse it across every path.
3. The log. Append-only history plus a recorded position enables durable state and replay-based recovery; this principle appears in database WALs, replication, event-sourcing journals, Kafka topics, CDC, streaming checkpoints, and agent step logs.
4. Budgets: staleness and guarantees, priced per question. Determine the acceptable answer age and identify who audits its correctness; dashboards may tolerate staleness, while invoices cannot; one stream can support both through different downstream guarantees.
5. Idempotency under at-least-once. Networks, frameworks, and agents all repeat operations; every external effect therefore needs a source-generated key that the sink honors, making repeated attempts harmless.
6. Ownership over agreement. Assigning one matcher to a driver, one writer to an account, or one consumer to a partition can remove distributed coordination. Single ownership and short leases often replace locks and coordinators.
7. Fail open vs. fail closed. Availability features may return reduced results, while financial and authorization decisions must refuse uncertain operations; in AI systems, text can degrade, but external actions must fail closed.

6. The Whiteboard Checklist

Use the five questions as a repeatable procedure for beginning any system design:

1. Flow: identify which callers wait synchronously and which work should enter asynchronous queues.
2. Storage: distinguish authoritative records from derived read models, caches, and indexes.
3. Speed: identify the most frequent reads and define their acceptable staleness before selecting caching tiers or precomputation.
4. Failure: for every dependency, define behavior when it stops responding, fails, or repeats a result; consider timeouts, retries, idempotency, breakers, and degradation.
5. Growth: identify which load dimension increases first, its likely bottleneck or hot key, and the metric that triggers scaling.

Apply the three habits introduced in the first lesson throughout this procedure:

• Numbers before boxes: run the arithmetic first and use it to reject unnecessary components.
• Every pattern pays its price aloud: name the cost in the same sentence as the pattern.
• Question four wins interviews: explicit failure behavior demonstrates complete operational reasoning.

If any row differs from your expected answer, review its linked lesson; then finish with the course conclusion.