Step 2 of 2 · your path
System Design, Advanced
The CAP theorem in depth, sharding at scale, distributed consensus, and the capacity math behind designing something like Twitter or Uber.
Your progress
0 / 16 done
Up next
CAP theorem in depth
19 min read
The order I'd read them in
About 5 h 43 min of reading. Tick off what you've read, it is remembered on this device.
- The CAP theorem in depthYou never "pick two" — you pick one letter during a partition, and PACELC tells you what you picked for the other 99.9% of the time.
- Transactions and isolationA transaction is a promise about what concurrent users can and cannot see, and the isolation level is how much of that promise you are actually buying.
- Storage enginesEvery database is a bet about how data should sit on disk, and most of what surprises you in production (slow writes, slow deletes, bloat, compaction storms) follows from that bet.
- Sharding & partitioning at scaleOne machine is a limit, not a bug — but the shard key you pick in week one is the decision you will still be paying for in year five.
- Time, ordering and IDsMachines disagree about what time it is, so a distributed design has to decide what to trust: the wall clock, a counter that only counts causes, or a clock that admits its own error.
- Distributed consensus (surface)Getting a group of unreliable machines to agree on one value — and why your job is to use a consensus system correctly, not to write one.
- Batch & stream processingThe same computation can run over data that has ended or data that never will, and almost every hard question is about what time means and when you are allowed to call an answer final.
- Designing for fault toleranceAt scale something is always broken — the design question is never "will it fail" but "what happens to everything else when it does".
- Observability at scaleMetrics say something is wrong, traces say where, logs say what — and p99 says whether anyone noticed.
- Release safety and incident responseMost outages follow a change. How to ship in small steps, watch the right signals, back out fast, and learn without blame.
- Capacity estimationThe whiteboard arithmetic that turns hand-waving into a design — no calculator, about three minutes, out loud.
- Real-world case studiesSix systems you use every week, one or two interesting decisions each, the bill that came with them, and what has changed since.
- Walkthrough: a key-value storeA Dynamo-style store is not one clever idea but eight ordinary ones bolted together, and the interview is about the decision you make at each seam.
- Walkthrough: a web crawlerA crawler is a loop that fetches pages and follows links, and every hard part is about not doing that too fast, too often, or forever.
- Walkthrough: a payment systemPayments are the one design where the traffic is small and the hard part is never losing, inventing or doubling a cent, so the whole chapter is about proving what happened.
- Tradeoff thinkingNobody is grading your architecture. They are grading whether you knew what you were giving up, and said so.
Practice at this level
No exercises tagged for this level yet. The ones on each chapter above still work.