system-design

How to Use This Guide

Reading this repo cover to cover will teach you almost nothing. Here is what actually works.

Prerequisites: What Is System Design? Time to read: ~10 minutes

The uncomfortable truth about reading

You can read the caching chapter three times, feel like you understand caching, and then freeze in an interview when someone asks “what happens to your cache when the database write succeeds but the cache invalidation fails?”

This is not a memory problem. It’s a retrieval problem. Recognizing information (“yes, I’ve seen write-through before”) is a different skill from producing it under pressure with nothing in front of you. Interviews test production. Reading trains recognition.

So the guide is built around a loop that forces production.

The loop

flowchart LR
    A[LEARN<br/>read the chapter] --> B[EXPLAIN<br/>3 min, out loud, no notes]
    B --> C[BUILD<br/>touch the real thing]
    C --> D[APPLY<br/>use it in a design]
    D --> E[REVIEW<br/>spaced repetition]
    E -.-> B

1. LEARN — read, but read actively

Read once at normal speed, no notes. Get the shape.
Read again with a pen. At each 🧠 / ⚖️ / 🚨 marker, stop and predict what it’s going to say before you read it. Being wrong is the point — a wrong prediction is what makes the correct answer stick.
Never highlight. Highlighting feels like learning and isn’t. Write a one-line summary in your own words instead.

Time budget: 30–45 minutes per chapter.

2. EXPLAIN — the step everyone skips

Close the laptop. Set a 3-minute timer. Explain the chapter out loud to an imaginary junior engineer. No notes.

You will hit a wall roughly 90 seconds in. That wall is the actual lesson. It’s the precise location of what you don’t understand. Go back, read only that part, and try again.

Do this or don’t bother with the rest. It is the single highest-return activity in this repo, and it costs three minutes.

If speaking to an empty room feels stupid: record a voice memo. Or explain it to a friend, your sibling, a rubber duck, or a chat window. The mechanism is the same — forced production.

3. BUILD — touch the real thing once

Every chapter has a 🛠️ Try it. These are deliberately small — 20 to 60 minutes, not weekends.

The purpose isn’t to build something impressive. It’s to convert abstract knowledge into physical memory. You will never forget what a cache stampede is after you’ve caused one on your own machine and watched the CPU graph.

Minimum viable setup: Docker, curl, and a terminal. That’s genuinely enough for 80% of the exercises.

4. APPLY — put it in a design

At the end of each roadmap week there’s a case study. Do it before reading the solution.

Set a timer for 45 minutes. Use paper or Excalidraw. Produce: requirements → estimates → API → data model → diagram → two deep dives.

Your version will be worse than the writeup. That’s fine and expected. The gap between your attempt and the writeup is information you cannot get any other way — you can’t discover you’d have forgotten to discuss the write path unless you first tried and forgot to discuss the write path.

Then grade yourself with the Self-Grading Checklist.

5. REVIEW — spaced repetition, cheaply

Keep one file: my-notes.md. After each chapter, add three lines maximum:

## Consistent hashing
- Problem: adding a server rehashes every key; consistent hashing moves only K/N of them.
- Trick: virtual nodes (100–200 per physical node) fix uneven distribution.
- Trap: it does NOT solve hot keys — one popular key still lands on one node.

Re-read the whole file every Sunday. It takes ten minutes at week 4 and twenty minutes at week 12. This is your entire revision system.

Choosing where to start

Be honest with the self-assessment, then:

Your situation	Start
Never deployed anything; unsure what a database index is	Part 1, chapter 1, Deep track
Built web apps, never thought about scale	Part 1, Standard track
2+ years professional, know the components, can’t structure an answer	Part 11, then Sprint track
Interview in under two weeks	The Framework, then Tier-1 and Tier-2 case studies

Do not start with case studies if you’re a beginner. Reading “Design Twitter” before you understand caching and sharding produces the illusion of learning — you’ll be able to recite the answer to that one question and be helpless on any variation. The case studies are the exam, not the textbook.

How to pace yourself

Consistency crushes intensity. 90 minutes a day, five days a week, for twelve weeks beats two frantic 8-hour weekends followed by quitting.

A realistic weekday session:

Minutes	Activity
0–5	Re-read `my-notes.md` from the last two days
5–45	Read the new chapter, actively
45–50	EXPLAIN out loud
50–80	BUILD (the 🛠️ exercise)
80–90	Write your three note lines

Weekends: one timed case study (45 min) + review (30 min).

Rules that will save you months

1. Never move on while confused. System design is a dependency graph, not a list. Sharding makes no sense if replication is fuzzy. Replication makes no sense if you’re shaky on consistency. Confusion compounds. Go back.

2. Don’t collect resources. You do not need this repo and three YouTube playlists and two paid courses and a book. Collecting materials feels productive and is procrastination. Use this guide plus, optionally, Designing Data-Intensive Applications. That’s it.

3. Argue with the guide. When you read “use a cache here,” ask: what if I didn’t? What would break? What would it cost? Chapters that can’t survive your questioning are chapters you didn’t understand. (And occasionally, the guide is wrong — open an issue.)

4. Always attach a number. Train yourself to never say “a lot of traffic.” Say “about 5,000 requests per second.” If you don’t know, estimate. An estimate you can defend beats a vague adjective every time.

5. Learn the failure story, not just the component. For every component, know three things: what problem it solves, what it costs you, and how it fails. Most candidates know only the first.

6. Do mocks with real humans. Starting from week 8, at minimum. Find someone on Discord, at work, from your university. Interviewing.io, Pramp, or a study partner. Solo practice cannot reproduce the pressure of someone watching you be stuck.

How to read the markers

Marker	Means
⭐	Disproportionately important chapter. Never skip.
🧠 Mental model	An analogy from outside computing. If the technical explanation didn’t land, this will.
📐 Numbers	Explicit arithmetic. Follow it with a calculator the first time.
⚖️ Trade-off	What this costs you. The part that makes you sound senior.
🚨 Interview trap	A specific way candidates lose points here.
🎙️ Soundbite	A sentence to say verbatim in an interview. Memorize the shape, not the words.
🛠️ Try it	Hands-on. Do it.
Check yourself	Collapsed Q&A. Answer before expanding, always.

What “done” looks like

You are ready for interviews when, given any of the case studies — including ones you have never seen — you can, in 45 minutes and without notes:

Ask 5–8 clarifying questions that meaningfully change the design
Produce scale estimates and state the assumptions behind them
Sketch an API and a data model
Draw a high-level architecture and justify every single box
Go three levels deep on any component the interviewer points at
Name what breaks first as traffic grows 10×, and what you’d do
State at least three trade-offs where you chose A over B and said what A costs
Recover gracefully when the interviewer says “that won’t work”

Note that “recite the standard answer to Design Twitter” is not on that list.

🎙️ Soundbite

“I don’t know the exact answer, but here’s how I’d reason about it…” — say this instead of freezing. See Handling Uncertainty.

→ Prerequisites & Self-Assessment → Then pick a track in ROADMAP.md

This site is open source. Improve this page.