Skip to main content
Course · 10 lessons

System Design Roadmap.

A system design course: requirements and API contracts, load balancing, caching, consistent hashing, rate limiting, capacity math and distributed consistency.

This curriculum builds system design fundamentals first, then the core algorithms that show up in almost every real design, then scaling and distributed correctness.

Suggested learning order

  1. System Design Essentials — requirements into a real, idempotent API contract
  2. Load Balancing — round robin vs least connections, with a real uneven-split distribution
  3. Cache Eviction — LRU vs LFU actually disagreeing on what to evict
  4. Capacity Estimation — turning stated assumptions into real QPS, storage, and bandwidth numbers
  5. Scaling & Reliability — retries with backoff and jitter
  6. Consistent Hashing — why adding a server shouldn’t remap everything
  7. Rate Limiting — token bucket and the fixed-window boundary bug
  8. Consensus — a Raft-style leader election, a split vote, and failover
  9. Distributed Locks — a real double-booking bug, fixed with a Redis lock
  10. Deep Dive: Quorum Consistency — when a read is guaranteed to see the latest write

The roadmap, step by step

1
system-design Step 1 of 10

System Design Essentials: Requirements Into a Real API Contract

Requirements and API design stay abstract until a client actually retries a request. An idempotency key turns that abstraction into working, testable code.

2
system-design Step 2 of 10

Load Balancing: Round Robin vs Least Connections

Round robin sends every server an equal share regardless of load; least connections adapts to which servers are actually busy right now.

3
system-design Step 3 of 10

Cache Eviction: When LRU and LFU Actually Disagree

LRU evicts whatever wasn't touched most recently; LFU evicts whatever was touched least often. The same access sequence can make them evict different keys.

4
system-design Step 4 of 10

Capacity Estimation: Turning Assumptions Into Real Numbers

Back-of-envelope math for QPS, storage, and bandwidth from stated assumptions, computed as real numbers instead of described in prose.

5
system-design Step 5 of 10

Scaling & Reliability: Retries With Backoff and Jitter

A naive retry hammers a struggling dependency at a fixed interval. Exponential backoff with jitter spaces retries out and spreads clients apart in time.

6
system-design Step 6 of 10

Consistent Hashing: Why Adding a Server Shouldn't Remap Everything

Plain modulo hashing remaps most keys when the server count changes. A hash ring with virtual nodes remaps only the fraction that actually has to move.

7
system-design Step 7 of 10

Rate Limiting: Token Bucket and the Fixed-Window Boundary Bug

A token bucket absorbs bursts then throttles once empty. A naive fixed window lets exactly double its limit through if requests cluster at the boundary.

8
system-design Step 8 of 10

Consensus: A Real Raft-Style Leader Election, Split Vote, and Failover

Simulate a 5-node cluster with real randomized election timeouts — a clean election, a genuine split vote, and a re-election after the leader is killed.

9
system-design Step 9 of 10

Distributed Locks: A Real Double-Booking Bug, Fixed With a Redis Lock

Two processes racing on the same booking slot really do double-book it. A Redis SET NX PX lock fixes it — a blind DEL unlock reintroduces the bug.

10
system-design Step 10 of 10

Quorum Consistency: When a Read Is Guaranteed to See the Latest Write

A write acked by W replicas and a read from R only guarantee overlap when W plus R exceeds the replica count -- otherwise a read can miss the latest write.