System Design in 15 Minutes: Recap & Cheat Sheet

This is the whole series squeezed into one page. It is a quick reference, so some words are short reminders. If a word is new, the post number tells you where to learn it. Read this page:

• before an interview or design review (15 minutes),
• when you forget a number or pattern,
• as a revision sheet after finishing the series.

Each section ends with the post numbers to read if you want more detail.

Interview time budget (45–60 minutes): requirements 5–8 · estimation 3–5 · API/data 5–8 · high-level 10–15 · deep dives 10–15 · wrap-up 2–5. QPS means queries per second. A "deep dive" means going into detail on one part of the design.

(Posts 6, 59)

Time conversions

• 1M requests/day ≈ 12 per second
• 100M requests/day ≈ 1,200 per second
• Peak ≈ 2–10× average (use ~3× if unsure)

Data sizes: KB = 10³ · MB = 10⁶ · GB = 10⁹ · TB = 10¹² · PB = 10¹⁵ (2¹⁰ ≈ 1,000). 1 GB/s ≈ 8 Gbps.

Latency (rough orders of magnitude)

What to learn from the table: memory is much faster than SSD, and SSD is much faster than a spinning disk. A network call inside one data centre (DC) is cheap. A call across continents is expensive. Reading data in order (sequential) is much faster than jumping around (random). Fewer round trips (a request and its reply) means a faster system.

Rough capacity guesses (always verify):

• one app server: hundreds to a few thousand simple req/s,
• one PostgreSQL/MySQL: thousands to tens of thousands of simple queries/s,
• one Redis node: ~100k simple ops/s,
• one WebSocket gateway: ~100k mostly idle connections (tuned).

(Posts 8, 10)

Average QPS        = requests per day ÷ 86,400Peak QPS           = average × 2–10Storage            = items/day × size × retention (× replicas if you manage them)Bandwidth          = QPS × response sizeCache size (80/20) = ~20% of daily hot dataServers            = peak QPS ÷ QPS per server  (+ headroom, + 1 zone failure)Little's Law       = in-flight requests = arrival rate × time per requestAvailability       = MTBF ÷ (MTBF + MTTR)Series             = A × B × C            (always lower)Parallel           = 1 − (1−A)(1−B)       (higher, if failures are independent)Error budget       = 1 − SLOBurn rate          = observed error rate ÷ allowed error rateQuorum             = W + R > N  → reads see the latest writeHit ratio          = cache hits ÷ total requestsRetry amplification = attempts per layer ^ number of layersBase62 codes       = 62^length   (6 → 56.8B, 7 → 3.5T)

Short guide to the words in the formulas. MTBF is the mean (average) time between failures. MTTR is the mean time to repair. SLO is a reliability goal, such as 99.9% of requests succeed. An error budget is the amount of failure the SLO still allows. Burn rate is how fast you are using up that budget. Quorum is the number of replicas that must agree: N is the total replicas, W is how many must confirm a write, and R is how many are asked on a read. Little's Law says the number of requests being handled at one time equals how many arrive per second times how long each one takes. Hit ratio is the share of requests answered by the cache.

(Posts 8–10, 24, 41, 47, 60)

• Each extra nine costs much more.
• Faster recovery (lower MTTR) is often the cheapest improvement.
• 99.9% × 3 services in series ≈ 99.7%. "In series" means a request needs all three services to work, so their availabilities multiply (0.999 × 0.999 × 0.999).
• Availability is the share of time a system works. "Nines" count the 9s in that number: 99.9% is "three nines".

(Posts 9, 47)

Part 1: Foundations (posts 1–5)

• DNS turns names into IP addresses. Answers are cached for a time set by the TTL (time to live). IP gives every machine an address. Routers forward packets, and BGP is the protocol that routers use to share which paths exist.
• TCP is reliable and keeps data in order, but it needs a handshake first. UDP is fast, with no guarantees. QUIC is a newer protocol built on UDP that adds reliability and encryption. It powers HTTP/3.
• HTTP: a method is the action of a request. GET, PUT and DELETE are idempotent (repeating them has the same result as doing them once). POST is not. Status codes: 2xx means OK, 4xx means a client error, 5xx means a server error. 502, 503 and 504 are different failures (bad gateway, unavailable, gateway timeout).
• TLS gives encryption, integrity (data is not changed on the way) and identity (certificates prove who the server is). A full TLS 1.3 handshake takes 1 round trip.
• Concurrency means doing many things in overlapping time. A process is a running program with its own memory. A thread runs inside a process and shares its memory. An event loop handles many tasks on one thread. A thread pool is a group of reusable threads. Never block the event loop, because everything else waits. A race condition is a bug where the result depends on timing. Fix it with atomic operations (one step that cannot be split), locks or the database.
• SQL: keys, joins (combine tables), indexes (lookup structures that speed up queries) and the left-prefix rule (a multi-column index helps only if the query uses its first columns from the left). EXPLAIN shows how the database runs a query. The N+1 problem means 1 query for a list plus N queries for each item. Connections are limited, so use connection pools (reused connections) and PgBouncer (a tool that shares few connections among many clients).

Part 2: Core concepts (posts 6–10)

• Requirements first, and make them measurable. Say what's out of scope.
• Vertical scaling (a bigger machine) vs horizontal scaling (more machines). Scaling out needs stateless servers, which keep no user data between requests.
• Latency is how long one request takes. Throughput is how many requests you handle per second. Use percentiles (p99), not averages. p99 is the time that 99 of 100 requests beat. The slow tail becomes common at scale: one request in 100 is still very many requests.
• Availability nines, series vs parallel, and MTBF/MTTR (average time between failures, and average time to repair).
• Estimate traffic, storage, bandwidth and servers, always ending with "so this means…".

Part 3: Building blocks (posts 11–19)

• Request path: DNS → CDN → LB → gateway → app → cache → DB, with queues on the side.
• Load balancers spread requests over many servers. L4 routes by IP and port. L7 reads the HTTP request. Algorithms: round robin (take turns), least connections (pick the least busy server), consistent hashing (the same key goes to the same server) and power of two choices (pick two servers at random, use the less busy one). Use shallow health checks: a quick test that the server itself is up, without testing every dependency.
• A reverse proxy sits in front of servers and handles TLS, compression, caching and routing. An API gateway adds auth, rate limits and routing. A BFF (backend for frontend) gives each kind of client its own API.
• CDN: caches files near users. The Cache-Control header tells the CDN how long it may keep a file. Hashed file names (the name changes when the file changes) avoid stale files. A purge removes cached files. An origin shield is one middle cache that protects your server.
• Caching: cache-aside means the app reads the cache first and fills it on a miss. Delete on write removes the cached item when data changes. Put a TTL on everything. LRU removes the least recently used item when the cache is full. LFU removes the least frequently used one. Defend against stampedes (many misses at once), avalanches (many items expire at once), penetration (requests for data that does not exist) and hot keys (one key with too much traffic).
• Object storage holds files. Use pre-signed URLs (links with time-limited permission) plus a CDN. Use lifecycle rules (move old data to cheaper storage) and keep files private by default.
• Queues decouple work (the sender does not wait), absorb spikes and scale with competing consumers (many workers share one queue). Messages may arrive twice.
• Search uses an inverted index (a map from each word to the documents that contain it), analysers (tools that split text into words) and BM25 (a formula that ranks results). Keep it in sync with CDC (change data capture, which sends database changes on). It can always be rebuilt.

Part 4: Databases (posts 20–29)

• SQL (joins, transactions, flexibility) vs NoSQL (key-value, document, wide-column, graph). Pick by access pattern.
• ACID is a set of four promises for transactions: atomic, consistent, isolated, durable. An isolation level sets how much running transactions can see of each other. Watch for lost updates (two writers overwrite each other) and write skew (two transactions each read the same data, then write different rows, and together break a rule). Fixes: atomic updates, FOR UPDATE (locks the rows you read), unique constraints, Serializable + retry.
• B-tree is a storage structure that is good for reads and updates data in place. LSM (log-structured merge tree) is good for writes. It writes in order, then merges files later (compaction). Bloom filters are small structures that quickly say "this key is definitely not here".
• Normalise (store each fact once) for correctness. Denormalise (store copies) on hot read paths, and keep the copies in sync.
• Replication: single-leader means one primary takes the writes. Async replication does not wait for replicas. Sync replication does. Replica lag causes problems such as read-your-writes failures (you do not see your own update). Failover means switching to a replica. Split brain means two nodes both think they are the leader. Multi-leader and leaderless systems use quorums.
• Sharding: split data by range, by hash or by a lookup directory. The shard key is critical. Watch for hot keys, cross-shard queries (queries that touch many shards) and resharding (moving data when you add shards).
• Consistent hashing: servers and keys sit on a ring. Virtual nodes spread each server around the ring. When you add a server, only about 1/N of the keys move.
• CAP: during a network partition (machines cannot reach each other), you choose consistency (C) or availability (A). PACELC adds: when there is no partition, you choose between latency and consistency.
• Consistency models go from strongest to weakest: linearizable (acts like one copy) → causal (cause comes before effect) → session guarantees (such as read-your-writes) → eventual (copies agree later). Choose per feature.
• Default: PostgreSQL + Redis. Add specialised stores only when needed.

Part 5: APIs (posts 30–34)

• REST: URLs are nouns (things), and HTTP verbs are the actions. Use correct status codes and consistent error messages. OpenAPI is a file format that describes your API.
• gRPC: a fast call format that uses Protobuf (compact binary data) over HTTP/2. It supports streaming and deadlines (a time limit that travels with the call). It needs L7 or client-side load balancing. It is mainly used between internal services.
• GraphQL: clients pick the fields they want. Watch for N+1 (fix it with a DataLoader, which batches lookups), cost limits (stop very expensive queries) and harder caching.
• Real time: polling (ask again and again) → long polling (the server holds the request until it has news) → SSE (the server sends, one-way) → WebSockets (both sides send, two-way). Scale with gateways + pub/sub.
• Idempotency keys make retries safe. Cursor pagination stays stable when the data changes. Versioning: add things, do not break old clients. Remove old versions slowly.

Part 6: Async & events (posts 35–39)

• Queue: each message goes to one consumer. Pub/sub (publish/subscribe): every subscriber gets a copy. You can combine them with fan-out (copy to many queues) or consumer groups.
• Kafka: a partitioned log, which is an ordered list of events split into parts. The key decides the partition, and a partition keeps order. Consumer groups share the work. An offset is a consumer's position in the log. Lag is how far behind a consumer is. Retention is how long events are kept. Compaction keeps only the latest event for each key.
• Delivery: at-most-once (a message may be lost), at-least-once (a message may arrive twice), and effectively-once = at-least-once + idempotent consumers.
• Outbox pattern solves the dual-write problem. That problem is: you must update the database and publish an event, and one of the two may fail.
• Jobs: keep payloads small (send IDs), make jobs idempotent, and work in chunks. Retry only for transient errors (short problems), with backoff + jitter. After that, send the job to a DLQ (dead-letter queue, where failed jobs wait for a person).
• Event-driven: an event says something happened. A command asks for something to be done. Choreography means services react to each other's events. Orchestration means one controller gives the orders. A saga with compensations is a long process where each step has an undo step.

Part 7: Reliability (posts 40–45)

• Find SPOFs (single points of failure: parts that stop everything if they break). Include the hidden ones: DNS, certificates, NAT, config, auth and people. Spread across 3 AZs (availability zones, which are separate data centres) and test failover (switching to a backup).
• Timeouts on every call. Retry at one layer only. Use exponential backoff + jitter: wait twice as long after each try, plus a random extra time. A retry budget caps the total number of retries.
• Circuit breaker: it is closed when calls work, open when the service keeps failing (calls are refused at once), and half-open when it lets a few test calls through. Add fallbacks (a simpler backup answer). Bulkheads keep resource pools separate, so one failure cannot use them all.
• Rate limiting caps how many requests a client can make. Token bucket is the favourite for APIs. Others are sliding window and leaky bucket. To share the limit across servers, use Redis + Lua (a Lua script runs as one atomic step in Redis). Return 429 + Retry-After, which means "too many requests, try again after this time".
• Load shedding (refuse some requests on purpose) and graceful degradation (turn off less important features) help under overload. Serve the most important traffic first.
• Backups ≠ replication. Use RPO/RTO (how much data you can lose, and how long you can be down), PITR (restore to an exact moment), the 3-2-1 rule (3 copies, 2 kinds of storage, 1 off-site) and immutable backups (they cannot be changed or deleted). Test restores.

Part 8: Observability (posts 46–48)

• Logs (what happened), metrics (numbers over time), traces (where time went for one request). OpenTelemetry is a standard toolkit for collecting all three.
• Watch Golden Signals (latency, traffic, errors, saturation), RED (rate, errors, duration) and USE (utilisation, saturation, errors). Avoid high-cardinality labels in metrics. A label has high cardinality when it has very many different values, such as a user ID. It makes metrics very costly.
• SLI → SLO → SLA. An SLI is a measured number (such as success rate). An SLO is the goal for it. An SLA is a promise to customers, often with penalties. Error budgets and burn-rate alerts tell you when you are using up the allowed failure too fast.
• Alert on symptoms, give every alert a runbook, mitigate first, and write blameless postmortems.

Part 9: Security (posts 49–52)

• AuthN (authentication: who you are) ≠ AuthZ (authorisation: what you may do). Check every object, to prevent IDOR (insecure direct object reference: a user changes an ID in the URL and sees someone else's data).
• Hash passwords with Argon2id or bcrypt (slow, one-way functions made for passwords). Add MFA (a second proof, such as a phone code) or passkeys (login with a device key instead of a password). Keep sessions in cookies with HttpOnly (page scripts cannot read it), Secure (sent only over HTTPS) and SameSite (not sent from other sites).
• A JWT (JSON Web Token) is a signed token. A normal JWT is signed, not encrypted, so anyone can read it. Keep them short-lived, and use rotating refresh tokens (a new refresh token each time you use one). Pin the algorithm, which means the server accepts only the signing algorithm you chose.
• OAuth 2.0 lets one app get limited access to your data in another app (delegated access). Use Auth Code + PKCE, the safe flow for browsers and mobile apps. OIDC (OpenID Connect) is login built on OAuth. It returns an ID token that says who you are.
• TLS everywhere, mTLS between services (both sides show certificates), KMS + envelope encryption (a key service protects the keys that encrypt your data), a secrets manager (a safe store for passwords and keys), and no secrets in code.
• OWASP (a group that lists common web risks): broken access control, injection (bad input runs as code; parameterise queries), misconfiguration, vulnerable components (patch them), SSRF (tricking your server into calling internal addresses) and supply chain attacks (attacks through the libraries you use).

Part 10: Architecture & deployment (posts 53–58)

• Monolith first (one application), then a modular monolith (one application with clear inner parts), then microservices (many small applications) when teams and scale demand it. Move step by step with the strangler fig pattern: new code slowly replaces the old code. Avoid a distributed monolith: services that are separate on paper but still depend on each other.
• Service discovery is how services find each other's addresses. Options: a registry with health checks, client-side or server-side lookup, DNS, or a service mesh (a layer of helper proxies that handles service-to-service traffic).
• Docker: an image is a packaged app. Layers are the steps it is built from. A multi-stage build keeps build tools out of the final image. Run as non-root, and keep no secrets in images. Use version tags, not latest, because latest can change without warning.
• Kubernetes: you describe the desired state, and Kubernetes keeps working until reality matches it (reconciliation). A Pod is the smallest unit that runs containers. A Deployment manages copies of Pods. A Service gives them one stable address. Ingress routes outside traffic in. Readiness says "ready for traffic", and liveness says "still alive, or restart me". Requests/limits set CPU and memory. HPA (horizontal pod autoscaler) adds or removes Pods as load changes.
• Cloud: regions contain AZs (use multi-AZ in production). IaaS gives you virtual machines. PaaS runs your code for you. Serverless runs functions on demand. In shared responsibility, the provider secures the cloud and you secure what you put in it. Egress costs are fees for data that leaves the cloud. IaC (infrastructure as code) creates servers from files.
• CI/CD: merge small changes often. A canary sends the new version to a few users first. Blue-green runs old and new side by side and switches. Feature flags turn features on or off. Expand-and-contract migrations add the new schema first and remove the old one later. DORA metrics measure delivery speed and stability.

Part 11: Case studies (posts 59–65)

See the one-liners in section 10 of this page.

• ☐HTTPS/TLS everywhere, mTLS internally, HSTS
• ☐Passwords hashed with Argon2id/bcrypt, MFA/passkeys available
• ☐Sessions in HttpOnly; Secure; SameSite cookies, or short-lived JWT + rotating refresh tokens
• ☐Authorisation checked on every object (tenant/user scoping)
• ☐Parameterised queries, input validation, output encoding
• ☐Rate limits on login, OTP and expensive endpoints
• ☐Secrets in a secrets manager, never in code, images or logs
• ☐Data encrypted at rest (KMS), sensitive fields tokenised or encrypted
• ☐Dependencies and images scanned and patched, SBOM kept
• ☐SSRF protections (allow-lists, block metadata IPs)
• ☐Security events logged and alerted on
• ☐Least privilege for users, services and cloud roles

(Posts 49–52)

(Posts 59–64)

Other classic problems to practise: web crawler, search autocomplete (trie + cache), YouTube (upload → transcode queue → CDN), Google Drive (chunked sync + object storage), ride-hailing (geospatial index + real-time location), payment system (idempotency + ledger + reconciliation), leaderboard (Redis sorted sets), distributed ID generator, key-value store, metrics/monitoring system.

Growth path: one server → separate DB → LB + stateless servers → cache + CDN → replicas + queues → split + shard → multi-region. Move only when the numbers say so.

(Post 68)

Do:

• ✅ Ask clarifying questions, and state your assumptions.
• ✅ Put numbers on everything (QPS, storage, latency).
• ✅ Start simple, then evolve ("v1 → at 10× we'd…").
• ✅ Walk each use case through your diagram.
• ✅ Compare options and explain trade-offs.
• ✅ Talk about failures, monitoring and security.
• ✅ Check in with the interviewer at each step.

Don't:

• ❌ Jump to Kafka, Kubernetes or microservices without a reason.
• ❌ Design for Google scale when the requirement is small.
• ❌ Use averages instead of p99.
• ❌ Forget that retries cause duplicates.
• ❌ Treat replication as backup.
• ❌ Spend all your time on one component.
• ❌ Stay silent. Think out loud.

1. Requirements and numbers first.
2. Start simple. Scale when measured.
3. Every choice is a trade-off. Say it out loud.
4. Data is the hard part: model, consistency, partitioning, backups.
5. Cache hot reads. Queue slow work.
6. Make every write safe to retry.
7. Everything fails: timeouts, retries + jitter, circuit breakers, redundancy.
8. Measure what users feel: p99, SLOs, symptom alerts.
9. Ship small, gradual, reversible changes.
10. Get the security basics right, everywhere.