System Design Cheat Sheet: The Tables I’d Print Before an Interview

This is the reference card, not the tutorial. Lookup tables for latency, datastore selection, and scaling patterns. Skim the morning of, not the night before. If you need the full process walkthrough, the minute-by-minute guide covers that.

Five questions to ask in minute one

1. What’s in scope? What’s explicitly out?
2. What’s the scale? (DAU, peak QPS, average payload size, read/write ratio.)
3. What’s the latency target? (p50, p99, separate per operation if reads and writes differ.)
4. What consistency model? (Strong, eventual, read-your- writes, monotonic.)
5. What region setup? Single-region or multi-region?

Latency numbers worth memorising

The Jeff Dean “numbers every programmer should know” list, updated for current hardware:

Two implications that come up in interviews: (1) a request that touches three services in series, each calling its own DB, can’t beat ~5ms even in the happy path. (2) Anything cross-region in the hot path is a design smell. Cache aggressively or shard by region.

Pick the right datastore

Pick the workload first. The datastore follows. The reverse order is how candidates end up justifying MongoDB for a join-heavy workload.

Scaling patterns by problem

CAP one-liner the panel actually wants

“Under network partition, you pick between consistency and availability. In practice, you pick eventual consistency for most user-facing reads and strong consistency only for the operations where stale data corrupts something: payment confirmation, inventory count, account balance. For everything else, eventual is cheaper, faster, and fine.”

That’s the answer. Don’t quote the CAP paper. Don’t draw the triangle.

Failure-mode checklist for the last 5 minutes

Walk the panel through each:

• What happens if the cache layer goes down? (Latency spike, degrade reads, don’t return 5xx.)
• What happens if a downstream service is slow? (Circuit breaker, timeout, fallback path.)
• What happens if traffic spikes 10×? (Auto-scale, load shed at the gateway, queue absorb.)
• What happens if a single shard becomes hot? (Resharding, request hedging, fan-out exception.)
• What happens during a deploy? (Canary, rolling, traffic split, automated rollback on error-rate alarm.)

References

The system-design-primer is the standard. The Google SRE Book is free online and has the load-shedding and SLO chapters every senior round expects you to have read.

Datastore selection, at a glance

The question is almost never “which database is best”. It is which access pattern you are optimising for, and what you are willing to give up.

Scaling moves, in the order you should reach for them

Interviewers notice when a candidate jumps to sharding before caching. The order matters more than the list.

1. Read replicas before anything exotic. Cheap, and most systems are read-heavy.
2. Cache the expensive reads. Decide the invalidation strategy out loud, because that is the follow-up question.
3. Add a queue to absorb write bursts and decouple slow work from the request path.
4. Denormalise the read path once joins become the bottleneck.
5. Partition or shard last. Say what the shard key is and what query it makes expensive.

Failure questions you should expect

Almost every design conversation ends here, and it is where mid-level and senior answers separate.

• What happens when this component dies? Who notices, and how fast?
• What is the blast radius of one bad deploy?
• Where does retrying make things worse rather than better?
• Which operation is safe to run twice, and which is not?
• What do you shed first when you are over capacity?

What people actually practise

A first-party number worth setting against any cheat sheet. Across 1,393 interview sessions configured on LastRound between January 2025 and July 2026, 14 were configured specifically for system design while 464 were DevOps engineering. System design is the round candidates say they fear most and prepare for least, which is a gap a reference sheet alone will not close.

Frequently asked questions

Is a system design cheat sheet enough to pass the round?

No, and relying on one is a common failure mode. The round tests how you reason under follow-up questioning, so memorised components help you start but not finish.

What do system design interviews actually score?

Whether you clarify requirements before designing, whether your trade-offs are explicit, and whether you can identify the bottleneck in your own design when pushed.

How much depth is expected at mid-level?

Enough to design a coherent system and explain where state lives, without needing deep expertise in every component. Senior candidates are expected to go considerably further on failure modes and scale.

Should I memorise specific numbers like latency figures?

Rough orders of magnitude help you reason out loud and are worth knowing. Precise figures rarely matter and reciting them without applying them reads poorly.

How do I practise system design alone?

Design something you use daily, then attack your own design as if you were the interviewer. Writing down the questions you cannot answer is the useful part.