Dev Learning
Start from scratch

Learn system design from nothing

No prior knowledge assumed. Read these five in order, then work through the topics one at a time. Every topic has a View more deep dive and a worked example at the end.

First, the ground floor

Five short lessons. After these, the vocabulary on the topic pages should be familiar.

1

What is system design?

Deciding how the parts of a product fit together, before anyone writes code.

2

How a system design interview works

Forty-five minutes, a vague question, and someone scoring how you think.

3

The five stages — the spine of every answer

One order to work in, so you never freeze in front of a blank whiteboard.

4

Where's the slack?

How much time the system has before a person notices. This one question shapes most designs.

5

The words you need, in plain English

A dozen or so words that unlock every other page. Nothing left undefined.

Then, the topics in order

Grouped so each stage builds on the last. You can jump around, but this order assumes the least.

04

More than one machine

The moment data lives in two places, a new set of problems starts. This is the senior material.

Availability, failover and the nines
How much downtime you are promising, and what it costs to promise less.
Replication
Keep the same data on several machines, and decide who is allowed to change it.
Partitioning (sharding)
Split the data so different machines own different pieces. It is how you scale writes past one machine.
Consistency models
Exact words for how out of date a read is allowed to be.
CAP and PACELC as real tradeoffs
When the network breaks you must choose: refuse the write, or accept it and be inconsistent.
Consensus, at concept level
How a group of machines agrees on one answer when some of them cannot be reached.
Clocks, ordering and why timestamps lie
Two machines never agree on the time, so never let time decide who wins.
Multi-region and data residency
Users on the other side of the world, laws about where data may live, and one very expensive round trip.
05

Doing work later

Queues, retries, and making it safe for the same thing to happen twice.

Message queues and backpressure
Write the job down now, do it soon, and survive the gap in between.
Idempotency, and why exactly-once is a myth
Make doing it twice the same as doing it once, because it will happen twice.
Fan-out: push vs pull
Do the work when one person writes, or when a million people read. This one choice designs the system.
Distributed transactions: 2PC, sagas, outbox
When one action must change two systems, and no transaction covers both.
Write-ahead logs
Write down what you are about to do, before you do it, so a crash cannot lose it.
Change data capture
Read the database's own log to find out what changed, instead of asking the application to tell you.
Batch and stream processing
Enormous volume in, aggregates out, and nobody waiting for any single event.
06

Common patterns

Specific reusable answers. Most of these appear as the follow-up rather than the first question.

CDNs
Put copies of your static content near users, so most requests never reach you.
Rate limiting
Say no cheaply, before the expensive part of your system finds out.
Consistent hashing
Add or remove a machine and move only a small slice of the keys, not all of them.
Bloom filters
A tiny structure that says "definitely not here" or "probably here", and never the wrong way round.
Distributed counters
Counting is easy until everyone counts the same thing at once.
Geospatial indexing
Turn "near me" into a range query, because databases cannot sort by two dimensions at once.
Search indexing basics
An index from words to documents, so "find me things containing this" is not a full scan.
Long polling vs WebSockets vs SSE
Three ways to push data to a browser, with very different costs at scale.
Circuit breakers and retries with jitter
Stop calling something that is already failing, and never retry all at the same moment.