The whole 23-part series on one page. Every section below is one idea, the problem that forces it, and what it costs - because in system design nothing is free, and the trade-off is the answer.
Read this to get oriented or to revise. The chapters go deeper, with the diagrams; the index is at the bottom.
Almost every idea in the series is a response to something that goes wrong on this path. Follow it once and the rest has somewhere to attach.
Every hop is a chance to be fast and a chance to fail. A name lookup, an edge that may already hold the answer, a balancer choosing among healthy servers, a cache that turns a disk read into a memory read, and finally the one component that must not lose your data.
You cannot reason about a system you are describing with an average. Chapters 1–3 are about seeing it as it is.
Latency is not one number, it is a distribution with a long right tail. p99 is the experience of your most valuable users - the ones with the fullest carts and the most data - because response time usually grows with how much of your product someone uses.
A dead dependency fails fast and you route around it. A slow one holds your threads, fills your queues and takes you down with it. Servers run out of five things - CPU, memory, disk, network, file descriptors - and knowing which one gave out is most of the diagnosis.
Chapters 4–8. Growth is easy until state gets in the way, which is why statelessness comes before load balancing rather than after it.
A bigger box is simpler and has a ceiling; more boxes have no ceiling and cost you coordination. Either way you cannot add the second server until the first one stops holding the session - move state out and the rest of scaling becomes arithmetic.
L4 moves packets, L7 understands requests and can route on their content. Round robin, least connections, hashing - the algorithm matters far less than whether the balancer notices a sick server.
A hit turns back early; a miss pays the full trip. Put bytes near users and you buy speed with staleness - the hard part was never caching, it is invalidation.
Chapters 9–15. Everything above can be rebuilt from a deploy; this part cannot. Durability, then read speed, then copies, then splitting up.
A write is durable when it is in the write-ahead log, not when the table is updated - that is the whole trick behind surviving a crash mid-write. Indexes then buy read speed, and every index is a tax on every write, which is why the planner sometimes ignores yours.
Asynchronous replication means a follower can serve a read that is seconds stale - sometimes fine, sometimes a user who cannot see the comment they just posted. Consistency models are promises about what a reader may observe, and CAP only forces a choice while the network is actually partitioned.
Read committed, repeatable read, serializable - each level stops more anomalies and costs more contention. Pick the level for the anomaly you actually have, and know whether your database gets there by locking or by keeping versions.
Hash-modulo-N moves almost every key when N changes. A ring moves only the neighbours, and virtual nodes stop one server inheriting a hot arc. The shard key is the decision you cannot cheaply undo.
Chapters 16–20. The moment work crosses a process boundary it can arrive twice, out of order, or not at all.
A queue turns a slow synchronous call into an accepted job and lets producer and consumer fail independently. But at-least-once delivery is the honest default, so the consumer must be idempotent or the customer gets billed twice.
A token bucket allows a burst then settles to a rate; a leaky bucket smooths throughout. What you key on - user, IP, tenant - decides who suffers when someone else misbehaves.
A majority cannot exist twice, which is what makes split-brain impossible rather than unlikely. And a lock that expires mid-work is worse than none, so a fencing token is the only real protection against the holder that came back from the dead.
Chapters 21–23. A design you cannot observe or safely change is a design you cannot keep.
Monitoring answers questions you knew to ask; observability lets you ask new ones during the incident. Latency, traffic, errors, saturation - page on what the user feels, not on what a machine is doing.
Blue-green, canary and rolling differ mainly in blast radius, and all three put two versions in production at once - so your schema and your API have to tolerate both. Separate the deploy from the release and a rollback stops being an emergency.
Measure before you change anything. Move state out so you can add servers. Put answers closer to users and accept staleness. Protect the data with a log, speed reads with indexes, copy it and admit the copies lag, split it on a key you can live with. Between services, assume duplicates and design for them. Then watch what users feel, and make change boring.
None of these are free. Caching trades freshness, replication trades consistency, sharding trades query flexibility, queues trade immediacy. Naming the cost is what separates a design from a wish list.
Each one goes considerably deeper than the summary above.
Part of the Engineering Notebook - 23 chapters plus standalone references. Written by Shailesh Mishra.