What should a system design cheat sheet include?

Five things, in the order you use them. First, the arc of the round — scope the problem, pin requirements, size it with back-of-the-envelope math, draw a naive version and break it on purpose, deliberate between 2–3 real architectures, go deep component by component in dependency order, then sweep the failures and wrap. Second, the numbers you carry in your head: the latency ladder (memory is fast, the network is a thousand times slower, a disk seek a thousand times slower again), a few per-box capacity anchors, and the formulas that turn users and payloads into QPS, storage, and bandwidth. Third, the building-block menu — load balancer, cache, CDN, SQL, NoSQL, object store, search index, message queue, stream processor, scheduler, WebSocket tier — each with the pressure that calls for it and the failure mode an interviewer probes. Fourth, the decision tables: SQL vs NoSQL, strong vs eventual consistency, cache-aside vs write-through, push vs pull, sync vs async, precompute vs on-demand. Fifth, the cross-cutting invariants a senior answer never skips: idempotency, backpressure, hot keys, fan-out strategy, honest exactly-once, and checkpointed resume.

What are the latency numbers every programmer should know?

The canonical ladder, credited to Jeff Dean (originally Peter Norvig), circa 2012: an L1 cache reference is ~0.5 ns, a branch mispredict ~5 ns, an L2 cache reference ~7 ns, a mutex lock/unlock ~25 ns, a main-memory reference ~100 ns, compressing 1 KB with Zippy ~3 µs, sending 1 KB over a 1 Gbps network ~10 µs, a random 4 KB read from SSD ~150 µs, reading 1 MB sequentially from memory ~250 µs, a round trip within one datacenter ~500 µs, reading 1 MB from SSD ~1 ms, a disk seek ~10 ms, reading 1 MB from disk ~20 ms, and a packet round trip from California to the Netherlands and back ~150 ms. The point is the ratios, not the digits: a disk seek is worth about 20 million L1 references, and a cross-continent round trip is worth about a million memory references. Memorize the shape.

How do I decide between SQL and NoSQL in a system design interview?

Default to SQL and only leave it when a specific pressure forces you off. A relational database gives you transactions, joins, and strong consistency for free, and most systems fit in one until they are genuinely large. Reach for NoSQL (key-value, wide-column, or document) when the access pattern is simple lookups by key at a volume a single machine cannot hold, and you need horizontal scale from day one. The trade you are making is explicit: NoSQL scales writes by partitioning on the key, but you give up joins and cross-row transactions and take on the job of denormalizing and keeping copies in sync yourself. Say the verdict first — "SQL unless the volume forces sharding" — then concede what each side costs.

What is the difference between fan-out on write and fan-out on read?

They are two ways to get one event to many readers. Fan-out on write pushes the event into every reader’s inbox at the moment it is created — reads become trivially cheap because the timeline is already assembled, but writes are expensive, and a single account with millions of followers turns one action into millions of writes (the celebrity hot-key problem). Fan-out on read does the opposite: it stores the event once and assembles each reader’s view on demand when they load — writes are cheap, but every read pays to gather and merge. Most large systems do both: fan-out on write for ordinary users, and fan-out on read for the few celebrities whose write-fan-out would be ruinous. Naming that hybrid is exactly the senior move.

How do you get exactly-once delivery?

You do not — not at the delivery layer, because a network that can drop and retry a message cannot promise it arrives exactly once. What is real is exactly-once effects: at-least-once delivery plus a dedupe or an idempotent write on the receiving end. The sender retries until it gets an acknowledgement (so the message is never lost), and the receiver makes applying the same message twice do the same thing as applying it once — by deduplicating on a message ID, or by using an upsert keyed by the event. Said precisely: the guarantee lives in the consumer, not the wire. Stating it that way in an interview shows you understand where exactly-once actually comes from.

The System Design Cheat Sheet

A hundred design prompts look like a hundred things to memorize — they are one method re-dialed. The meta layer above the worked examples: the eight-move arc of the round (scope, size, break the naive version, deliberate, go deep in dependency order, sweep the failures, wrap); the numbers you carry in (the Jeff Dean latency ladder on a live log scale, per-box capacity rules of thumb, the four QPS/storage/bandwidth formulas); the building-block menu with the failure an interviewer probes the moment you place each one; the six decision tables (SQL vs NoSQL, strong vs eventual, cache-aside vs write-through, push vs pull, sync vs async, precompute vs on-demand), verdict-first; and the six cross-cutting invariants a senior never skips (idempotency, backpressure, hot keys, fan-out, honest exactly-once, checkpointed resume). The signature exhibit is a prompt-decoder: pick a classic prompt and watch which blocks it pulls and which invariant dominates.

Concept · Systems. The source ↗

A free, interactive, animated visual explainer of The System Design Cheat Sheet — built to be understood, not skimmed.

Questions

What should a system design cheat sheet include?: Five things, in the order you use them. First, the arc of the round — scope the problem, pin requirements, size it with back-of-the-envelope math, draw a naive version and break it on purpose, deliberate between 2–3 real architectures, go deep component by component in dependency order, then sweep the failures and wrap. Second, the numbers you carry in your head: the latency ladder (memory is fast, the network is a thousand times slower, a disk seek a thousand times slower again), a few per-box capacity anchors, and the formulas that turn users and payloads into QPS, storage, and bandwidth. Third, the building-block menu — load balancer, cache, CDN, SQL, NoSQL, object store, search index, message queue, stream processor, scheduler, WebSocket tier — each with the pressure that calls for it and the failure mode an interviewer probes. Fourth, the decision tables: SQL vs NoSQL, strong vs eventual consistency, cache-aside vs write-through, push vs pull, sync vs async, precompute vs on-demand. Fifth, the cross-cutting invariants a senior answer never skips: idempotency, backpressure, hot keys, fan-out strategy, honest exactly-once, and checkpointed resume.
What are the latency numbers every programmer should know?: The canonical ladder, credited to Jeff Dean (originally Peter Norvig), circa 2012: an L1 cache reference is ~0.5 ns, a branch mispredict ~5 ns, an L2 cache reference ~7 ns, a mutex lock/unlock ~25 ns, a main-memory reference ~100 ns, compressing 1 KB with Zippy ~3 µs, sending 1 KB over a 1 Gbps network ~10 µs, a random 4 KB read from SSD ~150 µs, reading 1 MB sequentially from memory ~250 µs, a round trip within one datacenter ~500 µs, reading 1 MB from SSD ~1 ms, a disk seek ~10 ms, reading 1 MB from disk ~20 ms, and a packet round trip from California to the Netherlands and back ~150 ms. The point is the ratios, not the digits: a disk seek is worth about 20 million L1 references, and a cross-continent round trip is worth about a million memory references. Memorize the shape.
How do I decide between SQL and NoSQL in a system design interview?: Default to SQL and only leave it when a specific pressure forces you off. A relational database gives you transactions, joins, and strong consistency for free, and most systems fit in one until they are genuinely large. Reach for NoSQL (key-value, wide-column, or document) when the access pattern is simple lookups by key at a volume a single machine cannot hold, and you need horizontal scale from day one. The trade you are making is explicit: NoSQL scales writes by partitioning on the key, but you give up joins and cross-row transactions and take on the job of denormalizing and keeping copies in sync yourself. Say the verdict first — "SQL unless the volume forces sharding" — then concede what each side costs.
What is the difference between fan-out on write and fan-out on read?: They are two ways to get one event to many readers. Fan-out on write pushes the event into every reader’s inbox at the moment it is created — reads become trivially cheap because the timeline is already assembled, but writes are expensive, and a single account with millions of followers turns one action into millions of writes (the celebrity hot-key problem). Fan-out on read does the opposite: it stores the event once and assembles each reader’s view on demand when they load — writes are cheap, but every read pays to gather and merge. Most large systems do both: fan-out on write for ordinary users, and fan-out on read for the few celebrities whose write-fan-out would be ruinous. Naming that hybrid is exactly the senior move.
How do you get exactly-once delivery?: You do not — not at the delivery layer, because a network that can drop and retry a message cannot promise it arrives exactly once. What is real is exactly-once effects: at-least-once delivery plus a dedupe or an idempotent write on the receiving end. The sender retries until it gets an acknowledgement (so the message is never lost), and the receiver makes applying the same message twice do the same thing as applying it once — by deduplicating on a message ID, or by using an upsert keyed by the event. Said precisely: the guarantee lives in the consumer, not the wire. Stating it that way in an interview shows you understand where exactly-once actually comes from.

The System Design Cheat Sheet

Questions

Related explainers