System design cheat sheet

5 minReference

System design cheat sheet

The whole System Design track on a few screens: what to reach for when you see a symptom, the numbers worth remembering, the words engineers use, and what to read next. Keep it open during design reviews.

If you see X, reach for Y

Start with the cheapest fix in each row. Most problems are solved one or two rows down from where people first look.

You see	Reach for first	Then, if needed	Lessons
One query is slow	EXPLAIN (ANALYZE, BUFFERS), then the right index	Rewrite the query; fix N+1 in the ORM	Indexes, Query plans
The same data is read again and again	Cache-aside in Redis with a TTL	CDN for public files and pages	Caching, Files and CDNs
Database CPU is high from reads	Indexes and a cache	Read replicas; route reads that tolerate lag	Replication, Caching
A huge table, slow deletes of old rows	Partition by month, drop old partitions	BRIN index on the time column	Indexes, Partitioning
Writes outgrow one primary	Batch writes, fix hot rows, bigger machine	Shard by a key such as site_id	Sharding
Duplicate records after a retry or double tap	Idempotency key with a unique constraint	Natural keys such as (site_id, local_txn_id)	APIs, POS sales sync
Two users change the same row; one change is lost	Atomic conditional UPDATE	SELECT FOR UPDATE, or a version column	Transactions, No overselling
An endpoint is slow because of slow side work	Move the work to a queue; return 202	Pub/sub when several services care	Queues and jobs
Saved in the DB, but the event or message was lost	Transactional outbox	CDC as the relay	Outbox and sagas
A process spans services or a payment provider	Saga with compensating actions	Orchestrator for more than 3 or 4 steps	Outbox and sagas, No overselling
Retries make an outage worse	Timeouts, backoff with jitter, retry limits	Circuit breaker and a fallback	Timeouts and retries
Traffic spikes or abusive clients	Rate limit per key, return 429	Load shedding; a waiting room	Rate limiting, No overselling
One server is at its limit	Make the app stateless, add copies behind a load balancer	Autoscaling	Scale up vs out, Load balancers
"Too many connections" on Postgres	PgBouncer in transaction mode	Lower Prisma connection_limit per instance	Postgres ops
Users see old data right after saving	Read your own writes from the primary	Pin that user to the primary for a few seconds	Replication, CAP and consistency
Devices work offline or on flaky internet	Local DB plus outbox, idempotent upload	Change cursor for pulls; domain conflict rules	Offline sync, POS sales sync
Clients poll constantly for updates	SSE or WebSockets	Mobile push for apps in the background	Real-time
Dashboards slow down the main database	Materialized views, a replica	A warehouse fed by CDC or ETL	Data stores
A migration locked a table and stalled the app	lock_timeout; expand, migrate, contract	CREATE INDEX CONCURRENTLY in its own migration	Safe migrations
"It was slow for some users" and nobody knows why	p95/p99 metrics and a request id in every log	Distributed tracing	p99 and SLOs, Observability
Afraid of losing data	Backups with WAL archiving, and a tested restore	Point-in-time recovery drills	Backups
A user can see another user's data	Scope every query by the user's sites	Row-level security	Security

Numbers worth remembering

All latency numbers are orders of magnitude on typical hardware. Use them to compare options, not as exact figures.

What	Roughly	Use it to	Lesson
Memory read	~100 ns	See why caches and indexes in RAM are so fast	Estimation
SSD random read	~100 µs	Count disk reads per query	Estimation
Round trip inside one data centre	~0.5 ms	Price each extra network call (N+1, chatty services)	Estimation, Query plans
Spinning disk seek	a few ms	Know why random reads on HDD hurt	Estimation
Round trip to another continent	100+ ms	Decide where servers and CDNs must be	Estimation, Files and CDNs
Seconds in a day	86,400, about 10⁵	1 million requests/day ≈ 12 per second on average	Estimation
Peak factor	2 to 5 times the daily average	Plan for the busiest hour; festival rushes and push notifications go higher	Estimation
Requests in progress	rate × time per request	Size connection pools and worker counts	Estimation
Storage	rows/day × bytes/row × days, plus ~30% for indexes	Know when a table needs partitioning	Estimation, Partitioning
99.9% availability	~8 h 46 min down per year, ~43 min per month	Set SLOs and error budgets	p99 and SLOs
99.99% availability	~53 min down per year, ~4 min per month	See why each extra nine costs much more	p99 and SLOs
Two dependencies in series	99.9% × 99.9% ≈ 99.8%	Count what your request depends on	p99 and SLOs
B-tree lookup	3 to 4 page reads, even for millions of rows	Trust a good index on a big table	Indexes
One Postgres primary, small inserts	thousands per second on decent hardware	Avoid sharding a 10-writes-per-second system	Estimation, Sharding
Consistent hashing	adding a node moves ~1/N of keys	Compare with modulo, which moves almost all	Sharding
Base62 codes	7 chars ≈ 3.5 trillion; 10 chars ≈ 8 × 10¹⁷	Choose code length for guessability	URL shortener

The review loop on one line

Requirements with numbers, rough estimates, API and data, one diagram, deep dive on the hardest part, cover every box and ask what fails, trade-offs written down, then rollout, monitoring and cost. Decide, record it in an ADR, and name the owners (System design, Design reviews).

Glossary

Plain definitions of the terms used most in the System Design track, with the lesson that explains each one.

ACID: The four promises of a database transaction: all or nothing (atomic), rules kept (consistent), transactions do not see each other's half-done work (isolated), and committed data survives a crash (durable). Transactions
ADR (architecture decision record): A one-page note that records one important decision, the options considered, the consequences and when to revisit it. Design reviews
At-least-once delivery: Every message is delivered, but some may arrive more than once, so receivers must ignore repeats. Queues and jobs
Availability: The share of time a system answers correctly when called, often written in nines, such as 99.9%. p99 and SLOs
Base62: Writing numbers with 62 symbols (0-9, a-z, A-Z), so short codes stay URL-safe: 7 characters give about 3.5 trillion codes. URL shortener
B-tree: The default index structure in Postgres: a sorted tree that finds any row in a few page reads. Indexes
Cache-aside: The app checks the cache first, and on a miss reads the database and fills the cache with a TTL. Caching
CAP theorem: During a network partition, a distributed system must choose between staying consistent and staying available. CAP and consistency
CDC (change data capture): Reading a database's change log, such as the Postgres WAL, to stream every change to other systems. Data stores
CDN (content delivery network): Servers close to users that keep copies of files and pages, so most requests never reach your origin. Files and CDNs
Circuit breaker: A guard that stops calling a failing service for a while and fails fast instead, then tests it again. Timeouts and retries
Compensating action: A new action that undoes the effect of an earlier committed step, such as releasing reserved stock or refunding a payment. Outbox and sagas
Connection pooling: Sharing a small number of database connections among many app requests, for example with PgBouncer. Postgres ops
Consistent hashing: A way to map keys to servers on a ring so that adding or removing a server moves only a small share of keys. Sharding
Dead-letter queue (DLQ): A holding place for jobs that failed all their attempts, kept for a person to inspect and replay. Queues and jobs
Error budget: The amount of failure an SLO allows, such as 43 minutes a month at 99.9%, which the team can spend on change and risk. p99 and SLOs
Eventual consistency: Copies of data may disagree for a short time but will agree once updates stop arriving. CAP and consistency
Expand and contract: Changing a schema in safe steps: add the new form, move data and code over, then remove the old form. Safe migrations
Exponential backoff with jitter: Waiting longer after each failed retry, with a random part, so many clients do not retry at the same moment. Timeouts and retries
Horizontal scaling: Handling more load by adding more copies of a server instead of a bigger one. Scale up vs out
Idempotency key: A unique value the client sends with a request so the server can recognise a retry and return the first result. APIs
Idempotent: Doing it twice has the same effect as doing it once. Queues and jobs
Index: A separate sorted structure that points to table rows, so the database can find rows without reading the whole table. Indexes
Isolation level: How much concurrent transactions can see of each other's work: Read Committed (the Postgres default), Repeatable Read or Serializable. Transactions
Latency: How long one request takes from start to finish. Estimation
Load balancer: A server that spreads incoming requests across several app servers and skips unhealthy ones. Load balancers
Lost update: Two transactions read the same value, both write, and one change silently disappears. Transactions
Microservices: An application split into small services that are deployed separately and own their own data. Service boundaries
Modular monolith: One deployable application with strong internal module boundaries; a good default for a small team. Service boundaries
MVCC: Multi-version concurrency control: Postgres keeps old row versions so readers and writers do not block each other; vacuum cleans them up. Postgres ops
N+1 query: One query for a list, then one more query per item, which turns a single page into hundreds of round trips. Query plans
Negative caching: Caching the fact that something does not exist for a short time, so repeated lookups for it stop at the cache. URL shortener
Non-functional requirement: How well a system must work, with a number: how fast, how available, how much data. System design
Normalization: Storing each fact once and referring to it by key, so data cannot drift out of step. Data modeling
Object storage: A service such as S3 or MinIO that stores files by key, with presigned URLs for direct upload and download. Files and CDNs
Observability: Being able to tell what a system is doing from its logs, metrics and traces. Observability
Offline-first: An app that saves to a local database first and syncs with the server when the network allows. Offline sync
One-way door: A decision that is expensive or impossible to reverse, such as a public API or a core table; it deserves slow review. Two-way doors can be decided quickly. Design reviews
Outbox pattern: Writing an event to an outbox table in the same transaction as the data, then publishing it from there, so nothing is lost. Outbox and sagas
Partitioning: Splitting one big table into child tables by a key such as month, on one server; queries with the key scan only the right parts. Partitioning
Percentile (p95, p99): The value that 95 or 99 out of 100 requests are faster than; it shows the slow tail that averages hide. p99 and SLOs
PITR (point-in-time recovery): Restoring a database to any chosen moment, using a base backup plus archived WAL. Backups
Pub/sub: A publisher sends an event to a topic and every subscriber gets its own copy. Queues and jobs
QPS: Queries (requests) per second. Estimation
Quarantine: Keeping records that fail validation beside the good ones, with their error, so nothing is lost and bad data never reaches the main tables. POS sales sync
Queue: A durable list of jobs that workers take one at a time, so slow work happens outside the user's request. Queues and jobs
Quorum: The number of copies that must agree for a read or write to count; overlapping quorums (R + W > N) give consistent reads. CAP and consistency
RAG (retrieval-augmented generation): Finding the relevant documents first and putting them in the prompt, so an LLM answers from your data. AI features
Rate limiting: Capping how many requests a client may make in a period, answering 429 when it is exceeded. Rate limiting
Reconciler: A background job that compares your records with another system's, such as asking a payment provider about unconfirmed payments, and fixes the difference. No overselling
Read replica: A copy of the primary database, kept up to date from its WAL, that serves reads and is a little behind. Replication
RPO and RTO: Recovery point objective: how much data you may lose. Recovery time objective: how long you may be down. Backups
Saga: A business process split into local steps, each with a compensating action if a later step fails. Outbox and sagas
Sharding: Splitting data across several database servers by a shard key, so each server holds part of it. Sharding
SKIP LOCKED: A Postgres option that lets many workers claim different rows at once without waiting on each other. Transactions
SLI, SLO, SLA: What you measure (indicator), the target you set (objective), and the promise with penalties you sign (agreement). p99 and SLOs
Source of truth: The one place whose copy of a piece of data wins when copies disagree. Design reviews
Stateless service: A server that keeps nothing between requests, so any copy can answer any request. Scale up vs out
State machine: A model where something is always in one of a fixed set of states and only certain moves are allowed. No overselling
Token bucket: A rate-limiting method: tokens refill at a steady rate, each request spends one, and bursts are allowed up to the bucket size. Rate limiting
Trade-off: Getting more of one quality by accepting less of another, such as speed for freshness. System design
TTL (time to live): How long a cached value or DNS record is kept before it must be fetched again. Caching
Vacuum: Postgres's cleanup of dead row versions, run automatically by autovacuum; it also prevents transaction ID wraparound. Postgres ops
WAL (write-ahead log): Postgres's log of every change, written before the data files; used for crash recovery, replication and PITR. Replication
Webhook: An HTTP call another system makes to your server when something happens; verify it and expect retries. No overselling

What to read next

Designing Data-Intensive Applications by Martin Kleppmann. The best single book on databases, replication, partitioning, transactions and stream processing. Read it slowly, one chapter a week, alongside the Databases at Scale and Distributed Systems courses (start with Partitioning and CAP and consistency).
System Design Interview, volumes 1 and 2 by Alex Xu (volume 2 with Sahn Lam). Many worked designs in the same step-by-step shape as the System Design Case Studies course (URL shortener, POS sales sync, No overselling). Good practice for running the review loop.
Use The Index, Luke by Markus Winand, free at use-the-index-luke.com. How indexes really work, with examples for each major database. The natural next step after Indexes and Query plans.
The PostgreSQL documentation at postgresql.org/docs. Clear and complete. Start with the chapters on indexes, concurrency control and routine maintenance.
High Performance Browser Networking by Ilya Grigorik, free at hpbn.co. What really happens between the phone and the server: TCP, TLS, HTTP/2 and mobile networks. Pairs with Request journey and Networking.
Site Reliability Engineering and its companion books from Google, free at sre.google/books. SLOs, error budgets, monitoring and incident response, written by Google engineers who run very large systems. Pairs with p99 and SLOs and Observability.