Fourteen lessons of building blocks are useless if you can't pull them out of your memory under pressure. Picture a firefighter: knowing all the theory about how fire spreads doesn't help if they can't find the right hose in the dark in three seconds. This lesson is exactly that kind of muscle memory: the decision trees you run through at the whiteboard, the numbers you should be able to say without thinking, the phrases that earn real points, the reusable building blocks every design reaches for, and a self-test you can repeat until it gets boring.

Use this lesson three ways: read it once now, reread the recall cards the night before an interview, and run the drill at the very end of it, over and over, until every single answer comes back to you in under five seconds.

The one-page map

Here's everything in this section, laid out in the order you'll actually use it during a real interview.

Remember: the map has five stops in order: get the numbers, get the traffic in, get the data right, make the slow parts async, then keep it alive under failure.

Decision trees

Run through these from top to bottom, right at the whiteboard. Each one turns a question into an answer, plus the cost that answer carries with it.

Which datastore?

Reads are slow.

Writes are slow.

Client needs updates.

Two things must change together.

Something must happen exactly once.

Remember: each tree converts a symptom into an answer plus its cost. If your answer has no cost attached, you skipped a branch.

Reusable building blocks

Nearly every design you draw reaches for the exact same small toolbox. Knowing what each tool actually solves, and what it costs you in return, is what turns a plain box on a diagram into a decision you can actually defend.

A checklist for redesigning any system from scratch. Run any design prompt through these six steps, in order. First, requirements: 3 to 5 core features, plus the scale numbers, meaning daily users, requests per second, the ratio of reads to writes, and a latency target. Second, a capacity estimate: rough storage and bandwidth maths. Third, API design: 3 to 5 endpoints with their request and response shapes. Fourth, the high-level architecture: boxes for the client, load balancer, service, cache, database, and queue, and how data actually flows between them. Fifth, a deep dive: pick the ONE hardest part and go deep specifically on that. Sixth, bottlenecks and trade-offs: where does this design break at 10 times the scale, and what did you give up to get here.

Remember: each building block solves one problem and creates a new watch-out. Naming both halves is what separates "I'd add a cache" from a real answer.

Numbers and phrases to have on instant recall

Numbers worth memorising:

Phrases that earn real points. These are worth practising word for word, because under real pressure you tend to say whatever you've already rehearsed saying, not whatever you're trying to think up fresh in the moment:

1. "Before I design anything, what scale are we targeting, and is this read-heavy or write-heavy?"
2. "I'll scope to X and Y, and treat Z as out of scope unless you'd like it covered."
3. "That's 100 reads for every write, so the interesting problem is the read path."
4. "Anything the user's response doesn't depend on goes behind a queue."
5. "I'm choosing X. The cost is Y, and I'd soften it with Z."
6. "This is CP for the payment and AP for the product page; the choice is per operation."
7. "Writing to the database and publishing to the broker aren't one atomic action, so I'd use a transactional outbox."
8. "At-least-once delivery plus an idempotent consumer gives me effectively-once behaviour."
9. "Replication lag breaks seeing your own writes, so I'd route that user to the leader for a few seconds."
10. "Every real system has a hot key; here it's the celebrity account, and I'd handle it with a separate read path."
11. "Four synchronous dependencies at 99.9% each caps me at about 99.6%; I'd move two of them off the critical path."
12. "I'd alert on the checkout SLO, propagate a trace id into every log line, and add a daily reconciliation job."

Anti-patterns that lose points, so you can catch yourself doing them: drawing boxes before asking any requirements; naming technologies without justifying why; reaching for many small services, a message broker, or sharding at only 200 requests a second; claiming exactly-once delivery is actually achievable; presenting one design with no stated costs at all; going quiet while you think instead of narrating out loud; and running out of time because requirements alone took fifteen minutes.

Remember: rehearse the twelve phrases out loud until they come out naturally. Under pressure you say what you've already practiced saying, not what you newly think of.

The recall drill

Answer each question out loud, from memory, then check yourself against the lesson named in brackets. Aim for every answer to come back to you inside five seconds, with no notes. Repeat this drill often; the whole point is practising recall, not simply rereading the material again.

Round 1, the framework and the numbers

1. The six steps of a design interview, and the minutes given to each. [The System Design Interview Framework]
2. Seconds in a day, and what 1 million a day and 1 billion a day come to in requests per second. [Back-of-the-Envelope Estimation]
3. Memory versus SSD versus a cross-Atlantic round trip, in orders of magnitude. [Back-of-the-Envelope Estimation]
4. The four rows of the interviewer's scorecard. [The System Design Interview Framework]

Round 2, the request path 5. When to use SSE instead of WebSocket, and what WebSocket costs you architecturally. [Networking and Protocols for Design] 6. Why cursor pagination beats page numbers, and why the cursor needs a tie-breaker. [API Design and Idempotency] 7. What an idempotency key protects against, and which database feature makes it actually correct. [API Design and Idempotency] 8. L4 versus L7: one thing only L7 can do. [Load Balancing, Proxies, and Scaling Out] 9. Why a health check must not test the database. [Load Balancing, Proxies, and Scaling Out]

Round 3, data 10. On a write, do you update the cached value or delete it? Why? [Caching and CDNs] 11. Name the three cache failure modes and one fix for each. [Caching and CDNs] 12. An index on columns (a, b, c): which queries does it actually help? [Choosing a Database] 13. B-tree versus LSM-tree, in one sentence. [Choosing a Database] 14. Which problem does Read Committed still allow, and the three ways to prevent it. [Choosing a Database] 15. What does replication scale? What does partitioning scale? [Replication, Partitioning, and Sharding] 16. The three tests for a good partition key. [Replication, Partitioning, and Sharding] 17. Why hash(key) % N is a trap, and what fixes it. [Replication, Partitioning, and Sharding] 18. What the "P" in CAP actually means, and why "CA" isn't a real thing. [CAP, PACELC, and Levels of Consistency] 19. State PACELC, and give the everyday half of it. [CAP, PACELC, and Levels of Consistency] 20. The quorum rule for a read to see the latest write. [CAP, PACELC, and Levels of Consistency]

Round 4, async work and coordination 21. Queue versus log: the two questions that decide between them. [Messaging, Queues, and Event-Driven Architecture] 22. Why exactly-once delivery doesn't really exist, and what you say instead. [Messaging, Queues, and Event-Driven Architecture] 23. What the outbox pattern fixes, and how. [Messaging, Queues, and Event-Driven Architecture] 24. A saga: what replaces rollback, and the three obligations it places on you. [Distributed Transactions and Data Integrity] 25. Two-phase commit: what happens if the coordinator dies right after collecting the votes? [Distributed Transactions and Data Integrity] 26. What a fencing token is, and why a lease by itself isn't enough. [Coordination, Consensus, and Distributed Locks] 27. Why a Redis lock alone cannot guarantee correctness. [Coordination, Consensus, and Distributed Locks] 28. The cheapest way to run a nightly job exactly once, across 10 separate instances. [Coordination, Consensus, and Distributed Locks]

Round 5, operations 29. The availability of four synchronous 99.9% dependencies chained together, and the fix. [Reliability, Resilience, and Rate Limiting] 30. Four rules for handling retries safely. [Reliability, Resilience, and Rate Limiting] 31. The circuit breaker's states, and the transitions between them. [Reliability, Resilience, and Rate Limiting] 32. Token bucket versus fixed window: the two advantages of the token bucket. [Reliability, Resilience, and Rate Limiting] 33. What a metastable failure is, and how you escape one. [Reliability, Resilience, and Rate Limiting] 34. RED and USE: what each one is actually for. [Observability, Security, and Cost] 35. The JWT trade-off, and how it's usually softened. [Observability, Security, and Cost] 36. Expand, migrate, contract: why all three steps are needed. [Observability, Security, and Cost]

Round 6, apply it. Pick a system you use every day, like a food delivery app, a banking app, or a music streaming service, and give yourself six minutes: state the requirements, do the estimate, write one API endpoint, sketch one data model, draw one diagram, and name one bottleneck along with its fix and its cost. Six minutes, entirely out loud, no notes. Repeat this with a different system next time; it's the closest thing to a real interview you can practise entirely on your own.

Remember: rereading feels like learning but doesn't actually test recall. Answering out loud from memory, on a clock, is what actually sticks.

Quick recap

The two things worth memorising absolutely are the six-step framework and the 45-minute budget. Everything else, you can work back out from the decision trees once you're standing on the right branch. If a sentence you say in an interview doesn't include a real trade-off, it probably didn't earn you anything.