System Design Cheat Sheet on One Page

System Design Cheat Sheet on One Page

The system design interview is not testing whether you know what a load balancer is. It is testing whether you ask what you are building before you build it.

Candidates who start by drawing boxes lose. They design for a scale nobody specified, solve problems nobody asked about, and run out of time before the part that would have earned points.

This sheet covers the sequence first, then the numbers, then the components.

Updated for 2026.

The Sequence — Do These In Order

Step 1 is the one candidates skip. Ask what the system must do, what the non-functional targets are (latency, availability, consistency), and what is explicitly out of scope. Write it down where the interviewer can see it. That list becomes the contract everything else is graded against.

Three questions worth asking every time:

• How many users, and how active? Ten thousand daily users and ten million are different systems.
• Read-heavy or write-heavy? This single answer decides caching, replication, and database choice.
• Is stale data acceptable? If yes, most of the hard problems disappear.

What people get wrong: treating requirements as a formality and rushing to the diagram. The requirements are the design. Everything after is consequence.

Back-of-Envelope Numbers

Latency numbers worth memorising

These are approximate orders of magnitude, not benchmarks, and that is exactly how you should quote them.

The useful takeaway is the ratio, not the digits. Memory is roughly a thousand times faster than SSD, and a cross-continent round trip is roughly a hundred thousand times slower than memory. That is why caching and CDNs exist, and why chatty service-to-service calls destroy latency budgets.

QPS math

1 day ≈ 100,000 seconds   (86,400 — round it)

1 million requests/day   ≈ 12 QPS
100 million requests/day ≈ 1,200 QPS
1 billion requests/day   ≈ 12,000 QPS

peak QPS ≈ 2–3 × average QPS

Start from daily active users, multiply by actions per user per day, divide by 100,000. State the rounding out loud — interviewers are checking your order of magnitude, not your arithmetic.

Storage math

records/day × bytes/record × 365 × years × replication factor

Useful anchors: a short text row is roughly 1 KB, a compressed photo roughly 500 KB, a minute of video roughly 50 MB. Replication factor is typically 3.

Example: 10 million posts/day at 1 KB each is 10 GB/day, 3.6 TB/year, roughly 11 TB/year with triple replication. That comfortably fits on one machine, which is the point of doing the estimate — it tells you whether sharding is even a conversation.

Building Blocks

Load balancer

When to use: the moment you have more than one application server.

Algorithms: round robin (default), least connections (good for uneven request costs), consistent hashing (when a request should reach the same node repeatedly).

Avoid sticky sessions. They make servers stateful, which breaks autoscaling and turns any instance failure into a user-visible logout. Put session state in Redis instead.

Cache

When to use: read-heavy workloads with a hot subset — which is almost all of them.

Invalidation is the hard part, and there are only three honest options:

1. TTL expiry — simple, always works, guarantees staleness up to the TTL.
2. Explicit invalidation on write — accurate, but every write path must remember to do it.
3. Versioned keys — include a version in the key so old entries become unreachable and expire naturally.

The cache stampede problem: when a popular key expires, thousands of simultaneous requests all miss and hit the database at once. Fix with a short lock around the repopulation, or by staggering TTLs with a random jitter.

CDN

When to use: static assets, images, video, and anything cacheable served to a geographically spread audience.

A CDN stores copies at edge locations near users. It converts a 150 ms cross-continent round trip into a 10 ms local one and removes that traffic from your origin entirely. Cache-bust with content-hashed filenames rather than short TTLs.

Database replication

When to use: read-heavy load, or you need failover.

One primary takes all writes; replicas serve reads and follow the primary's log. This scales reads linearly and costs you replication lag — a replica may be milliseconds to seconds behind.

The consequence people forget: a user writes, immediately reads, and gets their old data back because the read hit a lagging replica. Fix by routing a user's reads to the primary for a few seconds after their write.

Replication does not scale writes. Every replica applies every write.

Sharding

When to use: last, after indexes, replicas, caching, and a bigger machine have all been exhausted.

Sharding splits data horizontally across independent databases by a shard key.

The shard key is the decision you cannot undo. It must spread load evenly and match your most common query. Sharding a social app by user ID is usually right; sharding by creation date guarantees every write lands on one hot shard.

What you permanently lose: cross-shard joins, cross-shard transactions, and easy ORDER BY across the whole dataset.

Message queue

When to use: slow work that does not need to finish before you respond, or when a spike must be absorbed.

Kafka, RabbitMQ, and Amazon SQS all do this. The queue decouples producer from consumer, so a burst of traffic queues up instead of collapsing the workers, and a worker crash costs you a retry rather than a lost job.

Most real systems use at-least-once and make consumers idempotent, which is far cheaper than genuine exactly-once delivery.

Rate limiter

When to use: any public API, login endpoint, or expensive operation.

Store counters in Redis with an expiring key, keyed by user ID or IP. Return HTTP 429 Too Many Requests with a Retry-After header.

Consistent hashing

When to use: distributing keys across a changing set of cache or storage nodes.

Plain hash(key) % N remaps almost every key when N changes, which empties your entire cache the moment you add a server. Consistent hashing places nodes and keys on a ring, so adding or removing a node only moves the keys between it and its neighbour — roughly 1/N of them.

Virtual nodes (each physical node placed at many ring positions) fix the uneven distribution that a small number of nodes otherwise produces.

SQL vs NoSQL

The honest default is a relational database. Modern PostgreSQL handles far more than most candidates assume, and it gives you joins and transactions for free. Justify NoSQL with a number — write volume, data size, or a genuinely key-value access pattern — not with a reflex.

What people get wrong: picking NoSQL because the system is "large scale". Scale is a quantity; state the quantity.

CAP Theorem in Plain English

When the network splits your system into groups that cannot talk to each other, you must choose:

The familiar "pick two of three" phrasing is misleading. Partition tolerance is not optional — networks fail whether you planned for it or not. The only real choice is what happens when they do.

Ask it as a product question: is a wrong answer worse than no answer? For a bank balance, yes — choose CP. For a like count, no — choose AP.

Consistency Models

Read-your-writes is the one that quietly matters most in product work. Users tolerate seeing someone else's post late; they do not tolerate their own comment disappearing.

The Five Mistakes

1. Drawing boxes before asking questions. Every minute spent on requirements saves five on redesign. If you have not written down what the system must do, you are not designing — you are guessing.

2. Designing for a scale nobody asked for. Sharding and multi-region for a system with ten thousand users is not sophistication, it is a failure to estimate. Do the QPS math first; it usually says one database is fine.

3. Adding a cache without an invalidation story. "We'll put Redis in front" is half an answer. Say what evicts entries, what the TTL is, and what a user sees when the data is stale.

4. Ignoring failure. Every box you draw will fail. State what happens when the cache is down, the queue backs up, or a replica lags — this is where senior candidates separate from mid-level ones.

5. Presenting a design with no tradeoffs. There is no correct architecture, only chosen tradeoffs. Ending with "I chose eventual consistency here, which costs stale reads and buys availability" is worth more than any diagram.

Print This Section

SEQUENCE  requirements → estimates → API → diagram → data model
          → deep dive on one bottleneck → tradeoffs

NUMBERS   1 day ≈ 100,000 s        1M req/day ≈ 12 QPS
          peak ≈ 2–3× average      memory ≈ 1000× faster than SSD
          cross-continent RTT ≈ 50–150 ms

SCALE UP  index → read replicas → cache → bigger box → shard (last)

BLOCKS    load balancer   >1 app server; L7 for routing
          cache           cache-aside default; TTL + jitter
          CDN             static assets, geographic spread
          replication     scales reads, not writes; lag is real
          sharding        pick the key carefully; it is permanent
          queue           slow work, spike absorption, idempotent consumers
          rate limiter    token bucket in Redis → 429 + Retry-After
          consistent hash ring + virtual nodes; only 1/N keys move

CAP       partition is not optional. CP = refuse. AP = stale.
          "is a wrong answer worse than no answer?"

DEFAULT   PostgreSQL until a number says otherwise

System design has no correct answer, only defensible ones. The candidates who do well are not the ones who name the most technologies — they are the ones who asked what was being built, estimated it, and said out loud what each choice cost.

🔗 Next in this collection: Networking Cheat Sheet, or return to The Complete Developer Cheat Sheet Collection.