System Design Interview Cheat Sheet: Numbers, Building Blocks and Trade-offs

Interview flow and timing

A system design interview rewards a visible plan. The split below fits a 45-minute round and adds up exactly; stretch the deep dives if you have an hour. Amazon's SDE II preparation page describes much the same shape from the interviewer's side: clarify vague requirements as if the interviewer were a customer, write down assumptions, consider what twice and ten times the growth would do, cover operations and failure points, and compare the trade-offs of the viable designs before choosing one.

Two habits keep you on schedule. Announce the plan in the first minute, and when a phase runs over, say so and move on. Interviewers can pull you back to a topic; they cannot give you back the ten minutes spent polishing an estimate that changed no decision.

• Amazon Jobs: SDE II interview prep
• How to prepare for a system design interview

Estimation numbers: powers of two and time

Back-of-the-envelope arithmetic needs very few constants. Each power of a thousand sits next to a power of two, so 2 to the 10th is about a thousand, 2 to the 20th about a million, and so on. A day has 86,400 seconds, which rounds to 100,000. That gives the most useful shortcut on the sheet: divide a daily count by 100,000 to get a rough per-second rate, so one million a day is on the order of 10 per second and one billion a day on the order of 10,000. The shortcut understates the true rate by about 14 percent, which is fine once you multiply by a peak factor.

State rounding out loud and keep one or two significant digits. The point of an estimate is to choose between designs, for example whether one database node is enough, not to be accurate to the percent. Always separate average from peak and name the multiplier you assume.

• The System Design Primer (GitHub)

Latency and availability numbers (approximate)

The latency figures below are the widely circulated “numbers every programmer should know”, as listed in the System Design Primer. They are old, rounded figures, and the published lists disagree: Peter Norvig's table, for example, gives 8 ms for a disk seek and 20 ms to read 1 MB from disk. Use them only for orders of magnitude. The ratios are what matter: memory is far faster than disk, a round trip inside a data center costs about half a millisecond, and a round trip between continents costs about 150 ms, as much as 300 round trips inside the data center.

Availability targets convert to downtime budgets, and the Google SRE book publishes the table; its month is 30 days. Two rules of composition come from the Primer: components in sequence multiply, so two 99.9 percent services in a chain give about 99.8 percent, and redundant components in parallel give 99.9999 percent if their failures are independent, which in practice they rarely fully are.

• 99% availability: 3.65 days of downtime per year.
• 99.9%: 8.76 hours per year, 43.2 minutes per month.
• 99.99%: 52.6 minutes per year, 4.32 minutes per month.
• 99.999%: 5.26 minutes per year.

• The System Design Primer (GitHub)
• Peter Norvig: Teach Yourself Programming in Ten Years (approximate timings table)
• Google SRE book, Appendix A: Availability Table

Building blocks and when each one appears

Nearly every design is assembled from the same dozen parts. For each one, know the property it buys, the signal in the requirements that calls for it, and its main cost. Introduce a block only when a requirement or an estimate justifies it; a diagram with a queue, a cache and three databases for a system that serves ten requests per second reads as memorized. The linked walkthroughs go into the mechanics of the blocks that interviewers probe most often.

• Load balancing algorithms compared
• Consistent hashing: ring and virtual nodes
• Sharding vs partitioning vs replication
• Design a rate limiter
• Redis cache-aside and cache stampede

System design trade-offs cheat sheet

Interviewers grade the reasoning behind a choice more than the choice. A complete trade-off statement has three parts: what you pick, what you gain, and what you knowingly give up. “I'll use cache-aside because reads outnumber writes about a hundred to one; the cost is stale data for up to the TTL and a slower first read” is a full answer. The table lists pairs that come up often. The cache row follows AWS's caching-strategies guide, which calls cache-aside lazy loading, and the consistency row follows the Primer's definitions; the rest is common engineering practice, stated without a single source.

• Amazon ElastiCache: Caching strategies (lazy loading, write-through, TTL)
• The System Design Primer (GitHub)
• REST vs GraphQL vs gRPC

Worked capacity estimate: a chat service

Here is a full estimate with every input labeled as an assumption: 50 million daily active users, 40 messages per user per day, 200 stored bytes per message, a peak three times the average, five years of retention, three replicas, a tenth of daily users connected at the peak, and 50,000 open connections per gateway server. The script was run with Python 3.12 and printed the values in the next paragraph.

Messages per day: 2,000,000,000. Average writes: 23,148 per second; peak: 69,444 per second. New data: 400 GB per day, 730 TB over five years for one copy and 2.19 PB with three replicas. Average ingress: 37.0 Mbit per second. Peak connections: 5,000,000, which needs 100 gateway servers. In an interview you would round as you go: 2 billion divided by 100,000 is 20,000 writes per second, close enough to 23,000 to make the same decisions.

Then read the decisions off the numbers. Tens of thousands of writes per second and petabytes of data rule out a single database node, so storage must be partitioned, most naturally by conversation. Bandwidth is small, so message bytes are not the problem; five million open connections are, which makes the connection gateway its own tier. Change one assumption, such as attachments at 200 KB each, and the bottleneck moves to object storage. Showing that sensitivity is worth more than the digits.

# Back-of-the-envelope estimate for a chat service. Every input is an assumption.
DAU = 50_000_000            # daily active users
MSGS_PER_USER = 40          # messages sent per user per day
BYTES_PER_MSG = 200         # stored bytes per message, with metadata
PEAK_FACTOR = 3             # peak traffic vs the daily average
RETENTION_YEARS = 5
REPLICAS = 3
ONLINE_SHARE = 0.10         # share of DAU connected at the peak
CONNS_PER_GATEWAY = 50_000  # open connections one gateway holds

SECONDS_PER_DAY = 24 * 60 * 60

msgs_per_day = DAU * MSGS_PER_USER
avg_writes = msgs_per_day / SECONDS_PER_DAY
peak_writes = avg_writes * PEAK_FACTOR
bytes_per_day = msgs_per_day * BYTES_PER_MSG
raw_bytes = bytes_per_day * 365 * RETENTION_YEARS
replicated_bytes = raw_bytes * REPLICAS
ingress_bits = avg_writes * BYTES_PER_MSG * 8
connections = DAU * ONLINE_SHARE
gateways = connections / CONNS_PER_GATEWAY

print(f"seconds per day      {SECONDS_PER_DAY:,}")
print(f"messages per day     {msgs_per_day:,}")
print(f"average writes/s     {avg_writes:,.0f}")
print(f"peak writes/s        {peak_writes:,.0f}")
print(f"new data per day     {bytes_per_day / 1e9:,.0f} GB")
print(f"5 years, one copy    {raw_bytes / 1e12:,.0f} TB")
print(f"5 years, 3 replicas  {replicated_bytes / 1e15:,.2f} PB")
print(f"average ingress      {ingress_bits / 1e6:,.1f} Mbit/s")
print(f"peak connections     {connections:,.0f}")
print(f"gateway servers      {gateways:,.0f}")

• Design a URL shortener: estimates and walkthrough

Mistakes this sheet is meant to prevent

The errors that cost the most are procedural. Candidates who know the material still lose time or credibility in the same few ways, and each has a quick fix you can rehearse.

• Drawing before asking: spend the first five minutes on requirements and scope.
• Estimating everything: compute only the numbers that change a design decision.
• Mixing units: write bytes, bits, per day and per second next to every figure.
• Forgetting the peak: state the average, then the multiplier.
• Naming a product instead of a property: say what the component must guarantee first.
• Quoting latency numbers as exact: say “on the order of”.
• No failure path: for each box, say what happens when it is down.
• A trade-off with one side: always say what the choice costs.

Turn the cheat sheet into recall practice

Reading a sheet feels like knowing it. Test that instead: cover the right-hand columns of each table and reproduce them, then redo the capacity estimate on paper with different inputs and check yourself with the script. Convert each row into a question, such as “what does write-through cost?” or “how much downtime is 99.99 percent per year?”, and answer aloud before looking.

Spaced review keeps the numbers available under pressure. The System Design Primer ships Anki decks for this purpose, and a spaced-repetition app such as RecallDeck does the same job for question-and-answer cards. Cards hold the vocabulary and the constants; they do not replace designing systems aloud against a timer, which the preparation guide and the question bank cover.

• How to prepare for a system design interview
• 52 system design interview questions
• Backend interview track

Quick answers

Frequently asked questions