Distributed Systems Curriculum

24 Chapters · Causally Sequenced · FAANG Interview Ready

The Spine

Everything in distributed systems is a response to one problem: computers and networks are unreliable, and you need to build reliable systems anyway.

Every chapter answers: "given the problem from the previous chapter, what do we do about it — and what new problem does that solution create?"

Part 1 — Physical Foundation (Chapters 1–3)

Before you can understand distributed systems, you need to understand what one machine can and cannot do. Every design decision that follows is a response to physical limits.

Chapter 1: The Speed of Physics Latency numbers every engineer must know cold. L1/L2/L3 cache → RAM → SSD → HDD → network. Why these numbers determine every trade-off in every chapter that follows. This is the Rosetta Stone — you'll cite it in every subsequent chapter.

Chapter 2: How a Database Actually Stores Your Data Pages, heap files, B-Trees from scratch. Why Postgres reads 8KB at a time. What a full table scan costs in real wall-clock time. How a row insert turns into a disk write.

Chapter 3: Indexes from First Principles What an index physically is (a separate sorted data structure). The math of why it turns O(n) into O(log n). When an index hurts (write overhead, index bloat). Composite indexes, covering indexes, partial indexes.

Part 2 — Replication: Making Data Live on Multiple Machines (Chapters 4–6)

You understand one machine. Now here's why one machine is never enough — and what copying data across machines actually costs you.

Chapter 4: Why Machines Die and What You Do About It MTBF math. Why redundancy is not optional at scale. Sync vs async replication — what you actually sacrifice with each. The replication motivation chapter.

Chapter 5: Leader-Follower Replication How replication lag works physically. Read replicas. Replication slots in Postgres. What happens during failover. The split-brain problem and why it's terrifying. This is PostgreSQL streaming replication, MySQL binlog replication.

Chapter 6: Consistency vs Availability — What "Consistent" Actually Means Linearizability, sequential consistency, eventual consistency — as physical phenomena, not definitions. CAP theorem (the real version, not the blog post version). PACELC (more useful in practice). When to choose what and why.

Part 3 — Partitioning: Spreading Data Across Machines (Chapters 7–8)

Replication solves reads and fault tolerance. It doesn't solve write throughput. When one machine can't handle the write load, you split the data.

Chapter 7: Sharding — Splitting the Database Range vs hash partitioning. Hot spots and how they kill you in production. The math of when you actually need to shard. Cross-shard joins: the constraint everyone forgets to hate until it bites them.

Chapter 8: Consistent Hashing Why naive hash(key) % N breaks catastrophically when you add or remove a node. The ring algorithm built from scratch. Virtual nodes (why they exist, what problem they solve). The Dynamo paper — this IS DynamoDB and Cassandra's partition scheme.

Part 4 — Performance: Making Distributed Systems Fast (Chapters 9–10)

The system is distributed and fault-tolerant. Now make it fast enough that users don't notice the complexity.

Chapter 9: Caching — The Right Data in the Right Place Client-side, CDN, server-side, DB-level — what lives where and why. Cache invalidation: why it's one of the hardest problems in CS. Eviction policies (LRU, LFU, FIFO). Cache stampede and how to prevent it. Write-through vs write-behind vs cache-aside.

Chapter 10: Write-Optimized Storage — LSM Trees Why B-Trees struggle at high write throughput (random I/O). MemTable → SSTable → Compaction. Write amplification vs read amplification vs space amplification — you can only optimize two. This is Cassandra, RocksDB, LevelDB, and BadgerDB.

Part 5 — Coordination: Making Machines Agree (Chapters 11–13)

Now the hardest problem in distributed systems: how do multiple machines agree on anything when messages can be delayed, lost, or reordered?

Chapter 11: The Consensus Problem Two Generals problem. Why distributed agreement is fundamentally hard (not just hard in practice — provably hard). FLP impossibility theorem in plain English. What Paxos is actually trying to solve. The setup for Raft.

Chapter 12: Raft — Consensus You Can Actually Understand Leader election. Log replication. Safety guarantees. What happens when the leader dies mid-write. How etcd, CockroachDB, TiKV, and Kafka (KRaft mode) work under the hood.

Chapter 13: Distributed Transactions Two-phase commit: what it does, why the coordinator failure turns it into a ticking time bomb. The Saga pattern as the practical production alternative. Exactly-once semantics — when it's real and when it's marketing.

Part 6 — Messaging: Decoupling Services (Chapters 14–15)

Services need to communicate without being tightly coupled. Queues and streams are the answer — but they introduce their own failure modes.

Chapter 14: Message Queues from First Principles Why queues exist (decoupling, backpressure, async work). At-most-once, at-least-once, exactly-once — the physical difference between them. Idempotency as the only real solution to duplicate delivery. SQS and RabbitMQ mechanics.

Chapter 15: Kafka — The Log Is the Database Why Kafka is dramatically faster than traditional queues (sequential vs random I/O). Log-structured storage — the append-only commit log. Consumer groups + offset tracking. When to use Kafka vs a queue. The event sourcing connection.

Part 7 — Traffic Layer (Chapters 16–17)

Traffic hits your system. Here's how to distribute it and protect it.

Chapter 16: Load Balancing L4 vs L7 — what each can see and act on. Algorithms: round-robin, least-connections, consistent hash (and why it matters for cache affinity). Sticky sessions. Health checks. Connection draining during deploys.

Chapter 17: Rate Limiting Token bucket, leaky bucket, fixed window, sliding window — the math and trade-offs of each. Distributed rate limiting with Redis. The race condition that breaks naive implementations. API gateway integration.

Part 8 — Observability (Chapter 18)

Your system is running. How do you know it's healthy? How do you diagnose failures you've never seen before?

Chapter 18: Logs, Metrics, and Traces — The Three Pillars Why each exists and what it can and can't tell you. Structured logging. RED method (Rate, Errors, Duration) for services. USE method (Utilization, Saturation, Errors) for infrastructure. Distributed tracing with OpenTelemetry — how a trace ID crosses 8 services. SLI, SLO, error budgets.

Part 9 — Synthesis: Design Real Systems (Chapters 19–24)

Apply everything. These chapters are structured exactly like a FAANG system design interview — requirements, estimation, design, deep dives, trade-offs.

Chapter 19: The System Design Framework How to structure any system design interview answer. Requirements → Estimation → API → Data model → High-level design → Deep dives → Trade-offs. The specific numbers you must know without looking them up. How interviewers score you.

Chapter 20: Design a URL Shortener The "hello world" of system design. Hashing, collision handling, database choice, caching strategy, scale estimation. Full end-to-end walkthrough of every decision.

Chapter 21: Design a Twitter/Social Feed Fan-out on write vs fan-out on read. The celebrity problem (Justin Bieber problem). Timeline generation at 500M users. The core problem pattern behind every social/feed system ever built.

Chapter 22: Design a Distributed Cache (Redis) Redis internals: single-threaded event loop, data structures, persistence (RDB vs AOF), cluster mode, consistent hashing inside Redis Cluster. Cache-aside vs write-through vs write-behind at scale.

Chapter 23: Design a Payment System The double-charge problem. Idempotency keys at scale. Exactly-once semantics for money. Audit logs as append-only truth. The Saga pattern for distributed payments. This is Stripe's actual architecture.

Chapter 24: Design a Notification System Push vs pull. Fan-out at 100M users. Delivery guarantees for notifications. Multi-channel (email, SMS, push, in-app). Rate limiting per user per channel. The scaling problem most candidates underestimate.

FAANG Coverage Map

The Chapter Prompt — Add This Block to Every Generation

When generating a chapter, add this block to your prompt:

CURRICULUM CONTEXT:
- This is Chapter [N] of 24 in a Distributed Systems curriculum
- Part [X]: [Part Name]
- Previous chapters covered: [list of chapter titles]
- This chapter's prerequisite concepts: [specific concepts from prior chapters student should already know]
- Next chapter will cover: [next chapter title and 1-line description]
- FAANG topics this chapter addresses: [list from coverage map above]
- Key latency numbers relevant to this chapter (from Chapter 1): [e.g., "network round-trip ~500µs, SSD read ~100µs"]

This block gives the chapter generator what it needs to connect forward and backward properly.

Reading Order

Start at Chapter 1. Do not skip. Every chapter assumes the previous one. The physical intuitions from Ch 1–3 are cited by name in Ch 4–18. The synthesis chapters (19–24) require genuine understanding of all prior chapters to answer fully — they cannot be memorised, only reasoned through.