4 min read

Quick Reads — Start Here

One concept per page. Seven minutes. Something you can say out loud in an interview.

The other system design sections are for learning. This one is for remembering.

Why this section exists

SD 1 and SD 2 go deep: chapters run to hundreds of lines and most of them have a simulation. That's the right way to learn a concept the first time. It's the wrong way to revise twenty of them the night before an interview.

Each Quick Read covers one concept in about seven minutes and always has the same shape, so you know where to look:

PartWhat it gives you
The storyA failure or a decision that shows why the concept matters. This is the part you'll remember.
The ideaThe concept itself, in plain words, with 3–5 diagrams.
The trade-offsWhen it helps, when it hurts, and what it costs.
The cheat sheetA table you can scan in thirty seconds.
Say it in the interviewOne or two sentences that sound like experience, not a definition.
Go deeperLinks to the long chapter or the sim, for when you want more.

The reads

The first six cover topics the rest of the site doesn't give a chapter of their own.

#ReadThe one-line idea
1Back-of-the-Envelope EstimationFive minutes of arithmetic tells you which box breaks first, before you draw any boxes.
2Horizontal vs Vertical ScalingA bigger machine is simpler than more machines. Use it until it stops being enough.
3The Database Scaling LadderIndexes, pooling, cache, bigger box, replicas, partitions, shards: climb in order.
4API GatewayOne front door that handles the boring parts of every request so services don't each reinvent them.
5Monolith vs MicroservicesSplit by team and deploy pain, not by noun. A modular monolith is usually the right first step.
6Data LocalityEvery network hop costs time and money. Move the computation to the data, not the data to the computation.

The next ones are short versions of topics covered in depth elsewhere. Each links back to its long chapter.

#ReadThe one-line idea
7Load BalancingSpread work, not requests, and route around sick servers with health checks that tell the truth.
8Caching and InvalidationCache-aside, delete on write, a TTL as the safety net, and protection against stampedes.
9Rate LimitingPer-caller limits so one client's bug can't become everyone's outage.
10CAP TheoremDuring a partition, choose an error or a possibly-wrong answer, per feature.
11ShardingChoose the shard key as if you can never change it, and map keys to many logical shards, not to machines.
12ReplicationSync standby for safety, async replicas for reads, and a plan for lag and failover.
13QueuesMove everything the user needn't wait for onto a queue. Expect duplicates, backlogs and poison messages.
14Fault Tolerance and IdempotencyTimeouts, careful retries, circuit breakers, bulkheads, and idempotency keys so retries are safe.
15Consistency ModelsLinearizable, causal, session, eventual: name the one each feature needs.
16Distributed TransactionsAcross services, use a saga with compensations, and an outbox to publish reliably.
17Leader ElectionLeases pick one leader. Fencing tokens stop a paused old leader from doing damage.
18Service DiscoveryCallers ask "where is X now?" by name, and only ready instances answer.
19CDNCache everything public at the edge, and make sure nothing private ever is.

How to use this section

  • Night before: read the cheat sheets only. Twenty concepts in twenty minutes.
  • Week before: read one full page a day and say its "Say it in the interview" line out loud until it doesn't sound memorised.
  • When a cheat sheet row surprises you: that's the concept to open in SD 1 or SD 2.
← Previous· SD 6 · Break My DesignDrill 14 — The Bad DeployNext →Back-of-the-Envelope Estimation