System design cheat sheet

The key takeaway of every lesson in the LogicWiz System Design course, in course order.

How to run a design interview

Boxes first is the mistake: Ask about requirements before you draw anything. Keep the design as small as the numbers allow. For every box, be able to say which requirement or number needs it.
Requirements: the questions that decide the design: Functional requirements say what it does; non-functional ones say how well, as numbers with units. State assumptions as numbers. Scope out loud, but never cut the hard part.

Estimating with round numbers: Requests per second is requests per day divided by 100,000. Multiply by a stated peak factor, and compute reads and writes separately. Aim to be roughly right, with every assumption said aloud.
From numbers to components: Compare your peak with rough ceilings: one database handles about 1,000 to 10,000 simple queries a second. A cache absorbs repeated reads. Replicas add survival and read capacity, never write capacity.

DNS, CDN, load balancers and the gateway: A load balancer spreads requests over stateless servers and uses health checks to skip dead ones. Use least connections when some requests are slow. A balancer spreads load; it does not create capacity.
Rate limiting and the entry layer that fails: A token bucket allows a steady rate plus short bursts. Reject excess with a 429, and keep counters in a shared store. The limiter, gateway and balancer each need a spare.

Designing the API: Use REST by default and WebSocket when the server must push. Page growing lists with a cursor, because offset repeats or skips items. Send an idempotency key so a retried payment charges once.
Modelling the data: List your access patterns first, and index only the queries that must be fast. Choose SQL or NoSQL per access pattern. Copy data on purpose only when it is read often and rarely changes.

Choosing a database, indexes and replicas: Choose a database by access pattern. Indexes turn a scan of millions of rows into a few reads but slow writes. Replicas add read capacity and a standby, but lag.
Sharding: splitting the data itself: Shard only when one primary cannot cope. Pick a shard key with many values and even load (customer id, not city). Consistent hashing moves only about 1/N of keys.

Why and where to cache: The database sees only the misses, so 99% hits means a tenth of the load of 90%. TTL trades freshness for hits. Write-through is safe; write-back is fast but can lose data.
The hard parts: invalidation, stampedes and hot keys: Invalidate with delete-on-write plus a TTL safety net. Stop stampedes with coalescing (one hot key) or jittered TTLs (many keys). The cache is a disposable copy, never the source of truth.

Queues: a buffer between fast and slow: A synchronous chain is as slow as its slowest link. A queue moves slow work out of the customer's wait and buffers bursts. Retry with backoff and jitter, then dead-letter.
Delivered twice, charged once: Exactly-once delivery is impossible, but idempotent consumers give exactly-once effects. An outbox ensures a saved change is always announced. A saga undoes failed multi-service steps with compensations.

CAP, quorums and eventual consistency: During a partition, choose to refuse (consistent) or answer possibly stale (available). Consistency costs latency even when healthy. R + W > N makes reads overlap writes. Read-your-writes protects the writer.
Leaders, locks and the interview answer: Expect two nodes to believe they lead, so the resource must check a fencing token. Raft uses terms and majority votes. In interviews, choose per feature: strong for money, eventual for counts.

Designing for failure: Parts in series multiply availability down; replicas help only if they fail independently. Give every call a timeout and retry at one layer only. Circuit breakers, bulkheads and graceful degradation stop one failure spreading.
Seeing your system: Metrics show that something is wrong, logs show what, traces show where. An SLO targets what users feel; 99.9% leaves an error budget of about 43 minutes a month. Page on symptoms, not causes.

Inside the database: B-trees and LSM trees: A B-tree finds a row in 3 or 4 page reads but rewrites a page per write. An LSM tree turns writes into appends and pays on reads. Pings suit LSM; orders suit B-trees.
Search and nearby: An inverted index maps each word to the products containing it; BM25 ranking picks the top ten. For "nearby", geohash cells turn a location into a string key. Always search the 8 neighbouring cells.

Serving answers from your own data (RAG): RAG pastes your own retrieved documents into the prompt: fine-tune for behaviour, retrieve for facts. Filter by permission before the prompt, and measure retrieval hit rate and faithfulness on a labelled set.
The LLM gateway: cost, speed and safety: One LLM gateway fronts all model calls. Cost is requests × tokens × price; set per-team token quotas. Use a first-token timeout, retry rarely, fall back to another provider, and treat retrieved text as untrusted.