system-design

Part 1 — Foundations

The physics of computing. Everything in the rest of this repo is a consequence of the constraints in these sixteen chapters.

Time for this part: 3 weeks on the Standard track (Weeks 1–3), 1 week on Sprint.

If you skip one part of this guide, do not let it be this one. Every technique later — caching, sharding, queues, CDNs — exists to work around a limit established here. Learn the limits and the techniques become obvious rather than memorized.

Chapters

# Chapter Time Why it matters
1 How a Computer Actually Runs Your Server 20 min CPU, memory, disk, network — the four things that ever run out
2 Networking 101: The Journey of a Request 20 min Every arrow in your architecture diagram, explained
3 IP, TCP, and UDP 18 min When to give up delivery guarantees, and why that’s sometimes correct
4 DNS: The Internet’s Phone Book 16 min Global routing, and a single point of failure people forget
5 HTTP, HTTPS, and TLS 22 min The protocol you’ll design APIs in, plus caching semantics nobody uses
6 HTTP/1.1 vs HTTP/2 vs HTTP/3 14 min Head-of-line blocking, and why HTTP/3 runs on UDP
7 Client–Server, Peer-to-Peer, and Between 14 min Who initiates, who holds state, and why that decides everything
8 Latency Numbers Every Engineer Should Know 12 min Nine numbers that let you reject bad designs instantly
9 Back-of-the-Envelope Estimation ⭐ 30 min The highest-leverage chapter in this repo
10 Latency, Throughput, and Percentiles 18 min Why the average is a lie and p99 is what users feel
11 Scalability: Vertical vs Horizontal 20 min Stateless vs stateful — the property that governs everything
12 Availability, Reliability, and the Nines 18 min Why more components means less availability
13 Consistency Models 20 min What “correct data” means across five machines
14 CAP Theorem (and why PACELC is better) 16 min The most misquoted idea in the field, stated properly
15 Concurrency, Parallelism, Threads, Async 18 min How one server serves 100,000 connections
16 Serialization: JSON, Protobuf, Avro, Thrift 16 min Usually your biggest CPU cost, and how deploys break

The through-line

These chapters build one argument:

Hardware has fixed speeds (ch 1, 8)
        ↓
Distance costs time you cannot recover (ch 2–7)
        ↓
So you must measure honestly (ch 9, 10)
        ↓
And when one machine isn't enough, you add machines (ch 11)
        ↓
Which introduces partial failure (ch 12)
        ↓
And disagreement about what's true (ch 13, 14)
        ↓
While each machine juggles thousands of requests (ch 15)
        ↓
Talking to each other in bytes (ch 16)

Everything in Parts 2–15 is a technique for living inside these constraints.

The five things to remember from Part 1

If you retain nothing else:

  1. RAM is ~1,000× faster than SSD; a cross-continent round trip is ~150 ms. These two facts justify caching, CDNs, replication, and most of your architecture.
  2. 86,400 ≈ 10⁵. One million requests per day is about 12 QPS. Most “huge” numbers are small.
  3. Stateless services scale horizontally; stateful ones don’t. Push state to systems built for it.
  4. Availability multiplies through dependencies and compounds through redundancy. Five services at 99.9% each gives you 99.5%.
  5. Consistency is a per-field decision, not a per-system one. Pay for strong consistency only where a stale read costs you money.

Before moving on

You should be able to answer these without notes:

If any of those are shaky, go back before starting Part 2 — the building blocks assume all of it.

Next: Part 2 — Building Blocks — the Lego bricks every system is assembled from.

This site is open source. Improve this page.