Cheat Sheets¶

Reference material, not teaching material. For the "why," follow the links into the concept pages. For the "what do I say in the next five minutes," this page.

System Design Interview Checklist¶

Work the steps in order. Naming a database before you have a requirement is the single most common way to lose a system design round.

The 7 Technical Areas That Actually Get Scored¶

The checklist above is the process — how to spend 45 minutes. This is the content — the technical ground you need to cover regardless of which product you're asked to design. Miss one of these and the interviewer has a specific, nameable gap to probe.

System Design: 10 Concepts That Actually Get Scored¶

A denser cut of the same ground as the two tables above — the failure modes that show up in real production incidents, not textbook chapter titles.

ACID Properties Quick Table¶

The properties a transaction gives you — and what actually breaks if you drop one. See DDIA Concepts for the full transactions/isolation-level treatment.

Performance Metrics: QPS, TPS, Latency, Throughput¶

Four numbers that get conflated constantly. Knowing which one moved — and why — is what separates "the system is slow" from an actual diagnosis.

How they relate under load:

flowchart TD
    A[Higher QPS / more users] --> B{System handles it well?}
    B -->|Yes| C[Latency stays flat<br/>Throughput scales up]
    B -->|No — saturated| D[Latency climbs<br/>Throughput plateaus or drops]

• QPS/TPS answer "how much load, and how much of it is real business work."
• Latency answers "how long did one user wait."
• Throughput answers "how much total work got done" — a system can have high throughput and terrible p99 latency at the same time (batching hides tail latency; see Tail Latency).

Worked example: an e-commerce flash sale — 10,000 concurrent users, 8,000 req/s, 2,000 orders/s successfully placed (TPS), average response time 420 ms, 120 MB/s transferred. The QPS number alone doesn't tell you the system is struggling; the fact that TPS (2,000) is well below QPS (8,000) and p95 latency has climbed does — most of the 8,000 requests/sec are retries and page-refreshes from users staring at a slow cart, not new demand. See Requirements & Estimation for turning these into capacity numbers before you design.

Big-O Complexity Cheat Table¶

Data structure operations¶

Sorting algorithms¶

Java's Arrays.sort uses Timsort for objects; primitives are typically dual-pivot quicksort (not stable). Python's sorted() / .sort() is always Timsort.

Graph algorithms¶

Common algorithmic patterns (interview shorthand)¶

See DSA for the full pattern library.

HTTP Status Code Quick Table¶

The ones interviewers actually ask about — know when to use which, not just the number.

Latency Numbers Every Engineer Should Know¶

Order-of-magnitude numbers for back-of-envelope math. Approximate, but the ratios between rows are the part that matters in an interview.

Rules of thumb this implies:

• Memory is ~100× faster than SSD, and SSD is ~10-20× faster than spinning disk.
• A same-DC round trip (~0.5 ms) is cheap; a cross-region round trip (~150 ms) is 300× that — never do it in a hot request path if you can avoid it.
• Network beats disk seeks: sending 1 KB over the LAN is faster than one HDD disk seek.

See Calculators for Little's Law and capacity math built on these numbers, and Engineering Math if it's filled in.

Distributed Systems Glossary — Quick Table¶

One line each. Full treatment is one click away.

Kubernetes: 10 Concepts That Actually Get You Paged¶

The list that matters in an incident, not the API surface. Full walkthrough (objects, request flow, guided diagnosis by symptom) at Kubernetes.

Pair this page with the Trade-off Matrix for comparisons and the Glossary for definitions outside distributed systems (databases, caching, general SWE terms).