System design interview practice is the discipline of turning everything you know about caching, databases, messaging, and resilience into a structured, timed conversation that a stranger can follow and grade in 45 to 60 minutes. It sits at the end of backend interview loops for mid-level through staff+ roles, and it exists because writing code alone doesn't prove you can reason about ambiguity, trade-offs, and scale the way a real engineering decision requires. The counterintuitive part is that the "best" design rarely wins the round; the candidate who narrates a clear, defensible thought process while covering requirements, estimation, a working high-level design, and one or two deep dives almost always outscores someone who silently draws a more elegant but unexplained diagram. Everything below assumes you already know the building blocks (caching, databases, load balancing, messaging, resilience patterns); this sheet is about the performance layer on top of that knowledge — the framework, the numbers, the talk track, and four worked case studies.
What This Cheat Sheet Covers
This topic spans 15 focused tables and 109 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: The Core Interview Framework and Time Allocation
Every system design interview, regardless of company or question, collapses into the same handful of phases; knowing the shape in advance is what keeps you from freezing on a blank whiteboard. Interviewers budget time against this shape whether or not they say so out loud, so matching it signals structure even before you've drawn a single box.
| Phase | Example | Description |
|---|---|---|
"Is this web, mobile, or both? What's the read/write ratio? How many DAU?" | • Establishes functional + non-functional scope before any design work • Budget 3-10 minutes; skipping it is the single most common cause of a failed round | |
POST /v1/tweets {text} -> {tweetId} | Naming the nouns (User, Post, Chat) and the request/response contract before drawing boxes gives the rest of the interview a shared vocabulary; budget ~5-7 minutes combined. | |
Client → LB → API service → DB, one box per functional requirement | • Walk through the API endpoints one by one, wiring up just enough architecture to satisfy each • Budget 10-15 minutes; resist adding scale-driven complexity here |