Cheat sheet

System design cheat sheet

Everything on one page for the last hour before an interview: how to run the hour, the numbers to know, which pattern fixes which problem, and the price of each. Every row links to the full explanation.

How to run the interview

1. Requirements (5 min) — State your assumptions, ask one or two questions that would change a box on the whiteboard, then propose the scope yourself.
2. Actors and lifecycle (6 min) — List who touches the system (including the system itself), then write the main thing's life as a chain of states. Then add the failure branches.
3. Numbers (6 min) — Estimate requests per second, storage and bandwidth. Then finish this sentence: "So the hard part here is ___."
4. High-level design (12 min) — Draw the boxes and arrows in words. Every box must be justified by a requirement from Stage 1 or a number from Stage 3.
5. Deep dive and tradeoffs (14 min) — Pick the two hardest parts and go deep. After every decision, say what it costs.

The full method, with examples: the five stages.

Numbers worth knowing

Read from main memory	~100 ns
Random read from an SSD	~100 µs
Round trip inside one data centre	~0.5 ms
Round trip across a continent	~50–100 ms
Round trip between continents	~150 ms
Seconds in a day	86,400 ≈ 10⁵
1 million requests a day	≈ 12 per second on average
1 KB × 1 million a day for a year	≈ 365 GB

Why these matter and how to use them: latency numbers and back-of-envelope estimation.

Which pattern for which problem

When you need to…	Reach for	What it costs
Reads far outnumber writes	Caching, Replication	Stale data; you own invalidation and replica lag.
Static files or media for users far away	CDNs, Object storage	Purging is slow; private content needs signed URLs.
One machine cannot hold the data or the writes	Partitioning, Consistent hashing	Cross-shard queries and transactions get hard; hot keys still exist.
Spread traffic over many servers	Load balancing	Servers must be stateless, or sessions must live elsewhere.
The database refuses connections or times out while idle	Connection pooling	A full pool queues requests; size it, and time out the wait.
A slow query on a large table	Indexes and slow queries	Every index slows writes and takes space.
Slow or bursty work that the user need not wait for	Message queues	Eventual results, retries, and duplicates to handle.
Retries must not charge or create twice	Idempotency	A key store, and a third outcome: unknown.
Protect a service from abuse or overload	Rate limiting, Circuit breakers	Some legitimate requests get rejected.
Push updates to clients as they happen	Polling, WebSockets, SSE	Long-lived connections are stateful and hard to balance.
One write must update many feeds or followers	Fan-out: push vs pull	Push is write-heavy for celebrities; pull is read-heavy for everyone.
Full-text or nearby-location search	Search indexing basics, Geospatial indexing	A second store that lags behind the source of truth.
Keep other systems in sync with the database	Change data capture, Distributed transactions	Ordering, replays and schema changes to manage.
Count something huge, approximately or fast	Distributed counters, Bloom filters	Approximate answers or delayed totals.

Every concept in one line

Measuring things

Performance vs scalability — Fast for one person is not the same as staying fast for a million. Cost: Chasing the wrong one wastes weeks.
Latency vs throughput — How long one thing takes, versus how many things you finish per second. Cost: Many techniques that raise throughput add latency, and many that cut latency leave capacity unused.
Latency numbers — Four numbers that tell you where the time goes. Cost: Memorising numbers can make you sound sure about a system you have never measured.
Back-of-envelope maths — Rough maths, done out loud, that tells you which problem you have. Cost: It takes time, and an early number can anchor you.

How a request reaches you

DNS — The phone book of the internet, and the step that happens before a client can connect at all. Cost: Answers are cached all over the internet: in the browser, the operating system, the router, the internet provider.
HTTP, TCP, UDP, RPC — How two machines talk, and which style to pick between your own services. Cost: Every step up in promises costs time.
API design — The contract you cannot change later, so get the three boring parts right now. Cost: Doing this well costs you flexibility up front.
Reverse proxies — One front door that handles the boring, repeated work before anything reaches your code. Cost: One more hop, one more thing to configure, and one more thing that can be set up wrongly in a way that affects everything at once.
Load balancing — One address in front, many machines behind, and a way to stop sending traffic to a broken one. Cost: It is one more hop (a fraction of a millisecond) and one more thing that can fail, so it needs a backup of its own.

Storing data

SQL vs NoSQL — Choose by how you read the data, and by what must never be wrong. Not by which word sounds bigger. Cost: Choosing relational costs you work once one machine is not enough.
Indexes and slow queries — A sorted lookup table, so the database stops reading every row. Cost: Every index makes writes slower, because each insert, update and delete has to update the index too.
Transactions and locking — What actually stops two people buying the last seat, inside one database. Cost: Every level of protection costs concurrency.
Connection pooling — Reuse a small set of open database connections, instead of opening one per request. Cost: The pool is a queue, so when it is full, requests wait.
Caching — Keep a copy of the answer near whoever keeps asking for it. Cost: You now have two copies of the truth, and they can disagree.
Object storage — Big files do not belong in your database, and they should not pass through your servers either. Cost: You now have two stores that can disagree.

More than one machine

Availability and failover — How much downtime you are promising, and what it costs to promise less. Cost: Every nine costs money and complexity.
Replication — Keep the same data on several machines, and decide who is allowed to change it. Cost: Copies take time to arrive, so a replica can serve data that is out of date.
Partitioning — Split the data so different machines own different pieces. It is how you scale writes past one machine. Cost: You lose the things that were free on one machine.
Consistency models — Exact words for how out of date a read is allowed to be. Cost: Stronger promises cost speed on every operation, and availability during failures.
CAP and PACELC — When the network breaks you must choose: refuse the write, or accept it and be inconsistent. Cost: Using CAP as a label makes you less accurate.
Consensus — How a group of machines agrees on one answer when some of them cannot be reached. Cost: Every decision needs a round trip to a majority, so it is slow compared to a local write, and it gets slower the further apart the machines are.
Clocks and ordering — Two machines never agree on the time, so never let time decide who wins. Cost: Doing it properly costs you simplicity.
Multi-region — Users on the other side of the world, laws about where data may live, and one very expensive round trip. Cost: Everything gets harder and more expensive.

Doing work later

Message queues — Write the job down now, do it soon, and survive the gap in between. Cost: The user gets "we received it", not "it is done", and your product has to say so.
Idempotency — Make doing it twice the same as doing it once, because it will happen twice. Cost: You need somewhere to remember what you have already done: a key store with a retention window.
Fan-out: push vs pull — Do the work when one person writes, or when a million people read. This one choice designs the system. Cost: Push costs write amplification: one action becomes a million writes, storage for a million copies, and a backlog that delays everybody when one big account posts.
Distributed transactions — When one action must change two systems, and no transaction covers both. Cost: Every option here is worse than a local transaction.
Write-ahead logs — Write down what you are about to do, before you do it, so a crash cannot lose it. Cost: Every write happens twice, once to the log and once to the data, so you pay in disk speed and space.
Change data capture — Read the database's own log to find out what changed, instead of asking the application to tell you. Cost: The consumer sees database rows, so it is tied to your schema.
Batch and stream — Enormous volume in, aggregates out, and nobody waiting for any single event. Cost: Streaming buys freshness and pays with complexity: late and out-of-order events, state you must keep in the middle of a running job, and a much harder story when you need to fix a bug in yesterday's numbers.

Common patterns

CDNs — Put copies of your static content near users, so most requests never reach you. Cost: You now have copies of your content everywhere, and clearing them is not instant.
Rate limiting — Say no cheaply, before the expensive part of your system finds out. Cost: You will sometimes reject real traffic, and it hits your biggest customers hardest, along with anyone behind a shared IP address: an office, a university, a mobile network.
Consistent hashing — Add or remove a machine and move only a small slice of the keys, not all of them. Cost: It is more complex than a remainder, and someone has to maintain the ring: which nodes exist, and getting every client to agree on that view.
Bloom filters — A tiny structure that says "definitely not here" or "probably here", and never the wrong way round. Cost: It can say yes when the answer is no.
Distributed counters — Counting is easy until everyone counts the same thing at once. Cost: Every technique here trades exactness or freshness for throughput.
Geospatial indexing — Turn "near me" into a range query, because databases cannot sort by two dimensions at once. Cost: The mapping is rough at the edges.
Search indexing basics — An index from words to documents, so "find me things containing this" is not a full scan. Cost: A second copy of your data that can drift from the source, and now you own keeping it in step.
Polling, WebSockets, SSE — Three ways to push data to a browser, with very different costs at scale. Cost: All of them mean holding connections open, so your servers now hold state in a way plain request-response does not.
Circuit breakers — Stop calling something that is already failing, and never retry all at the same moment. Cost: A circuit breaker returns errors for requests that might have worked, so you trade away some successful requests on purpose for the survival of the system.

In production

Auth and secrets — Who are you, what are you allowed to do, and where do the keys live. Cost: Security is friction you pay on every request, forever.
Observability — How you find out something is broken, and how you find out why, at three in the morning. Cost: Observability is expensive, and the cost surprises people.
Deploys and releases — Most outages start with a change you made on purpose. This is how you make that survivable. Cost: Safety slows you down.
Backups and DR — Two numbers: how much data you can lose, and how long you can be gone. Cost: Backups cost storage, and the good ones cost more: frequent snapshots plus continuous log archiving is not cheap at scale.
Capacity planning and cost — What the design costs per month, and which line of the bill you would attack first. Cost: Optimising for cost always costs you something else.

Want to test yourself rather than read? Revise tracks what you have covered, and the practice problems make you use all of this at once.