This is not a textbook. After 6 or more years of work you know most of this already, and so the job is to find the parts that have gone rusty, in the time you have. The chapter gives a map: the topics a senior loop tends to touch, how deep to go at each level, and a free, official place to refresh each one. The depth guides are the author's judgement. They are not taken from any company's rubric, and no frequency claim ("most asked") is made, because the author has not counted one for this chapter.
How to use the map
Do this in week 3 of the calendar. For each row below, rate yourself in one of three states. Then spend your hours only on the yellow and red ones.
- Green: I could explain it for ten minutes to a peer, with an example from my own work.
- Yellow: I know the idea but I would stumble on a follow-up.
- Red: I could not explain it without looking it up.
Depth is relative to level. A Senior needs to explain and apply a topic. A Staff candidate needs to explain why it fails, what it costs, and when to pick something else. The same topic has three depths; the table says which to aim for. Level definitions are in the levels chapter.
The depth scale
| Depth | You can | Typical level |
|---|---|---|
| 1: name it | Say what it is and when it is used | Enough for rarely probed topics |
| 2: use it | Explain how it works, give a use and one failure mode | Senior |
| 3: argue it | Compare it with alternatives, cost it, and say what would make you change your mind | Senior on your own domain; Staff on most |
| 4: build it | Describe the internals well enough to reimplement the core idea | Staff on two or three topics only |
System design fundamentals
Here, "free official" means the project's own documentation or its authors' own papers, which cost nothing to read. Use them to refresh, not to learn from zero.
| Topic | Senior depth | Staff depth | Free place to refresh |
|---|---|---|---|
| Estimation: QPS, storage, bandwidth | 2: two numbers that change a decision | 3: cost per unit, headroom, growth | Your own system's real numbers; no book needed |
| Replication, leaders, followers | 2 | 3 to 4 | Raft site (paper and an interactive visualisation) |
| Consistency and consensus | 2: what the user sees | 3 to 4 | Raft site; the Google SRE book, chapter on distributed consensus |
| Partitioning and hot keys | 2 | 3 | The Dynamo paper, linked from Werner Vogels' post |
| Transactions and isolation levels | 2 to 3 | 3 | PostgreSQL documentation, Transaction Isolation |
| Global databases and clocks | 1 to 2 | 3 | Spanner paper page |
| Retries, timeouts, backoff, load shedding | 2 to 3 | 3 | Amazon Builders' Library; the SRE book chapters on overload and cascading failures |
| Monitoring and alerting | 2 | 3 | SRE book chapters on monitoring and alerting |
| Queues and delivery guarantees | 2 to 3 | 3 | The documentation of whichever broker you use at work |
| Caching and invalidation | 2 to 3 | 3 | The documentation of the cache you use |
| Rate limiting, idempotency | 2 | 3 | Builders' Library; your own payment or API code |
Everything else in design is built on these. The method for using them in a round is in the design script and how to drive a design; follow-up questions are in the follow-up bank.
What a Staff-level follow-up looks like
One example of the jump from Senior to Staff depth: "Why not use a distributed lock here?". At Senior, you say what a lock does and that it can expire. At Staff, you say what happens when the holder pauses past its expiry, what a fencing token is, and when you would avoid the lock and use a conditional write. The refresher for this is the consensus material above, plus the documentation of whichever store you would use. Do not stop at the sound bite. Run the failure out loud.