Part 0 — Getting Started
Start here even if you're experienced: §1 defines the vocabulary used throughout and how the interview is scored, and §2 is the framework that every later chapter, case, and walkthrough follows.
1. What System Design Is, and How the Interview Works
1.1 System design in one page (start here if you're new)
System design is deciding which components a software product needs, how data flows and is stored between them, and what happens when things go wrong, so the product keeps working as it grows from a hundred users to a hundred million, at a cost the business can afford.
A photo-sharing app for 100 users is one server and one database. For 100 million users the same features need load balancers, caches, many database machines, a CDN for images, background workers, monitoring, and a plan for when any of those fail. System design is the reasoning that gets you from the first picture to the second, and the trade-offs you accept along the way.
The vocabulary you'll meet first (each term is taught properly in the section shown; you don't need it all now):
| Term | Plain meaning | Taught in |
|---|---|---|
| Latency | How long one request takes (e.g. 120 ms) | §3, §14 |
| p50 / p99 | Percentiles: p99 = 99% of requests are faster than this. Averages hide slow requests, so designs target p99 | §16 |
| Throughput / QPS | How many requests per second the system handles | §3 |
| Availability, "nines" | Fraction of time the system works: 99.9% ≈ 8.8 h down per year | §14, §27.3 |
| Scalability | Handling more load by adding capacity: bigger machines (vertical) or more machines (horizontal) | §4, §8 |
| Cache | A fast copy of frequently read data, usually in memory | §7 |
| Replication | Keeping copies of data on several machines, for safety and read capacity | §8, §10 |
| Sharding (partitioning) | Splitting data across machines because it no longer fits on one | §9 |
| Consistency | Whether every reader sees the latest write immediately (strong) or after a short delay (eventual) | §10 |
| Queue / stream | A buffer that lets work happen later, asynchronously | §11 |
| Idempotency | Doing an operation twice has the same effect as once, which makes retries safe | §5.2 |
| SLO | An internal reliability target, e.g. "99.9% of checkouts succeed in < 300 ms" | §16 |
| Trade-off | Every choice buys something and costs something; naming both is the core interview skill | everywhere |
1.2 The four signals interviewers write up
Rubric names differ by company, but almost every tier-1 company's feedback form reduces to these four signals:
- Problem navigation: Did you get from a vague prompt to a crisp problem statement without being led? Did you prioritize what matters?
- Solution design: Is the architecture coherent, does it meet the requirements, and are the components used for the right reasons?
- Technical depth and excellence: When pushed on one component, do you understand how it really works (not just its name), and its failure modes?
- Communication and collaboration: Was the design easy to follow? Did you take hints, handle pushback, and explain trade-offs without being defensive?
For engineering manager loops (EM, Sr. EM, Director), add a fifth: execution and org judgment. How would you staff it, sequence it, de-risk it, and run it in production?
1.3 How the bar changes with level
Every senior level is scored on the same four signals. What changes is how far each signal is expected to go: a Senior engineer produces a complete, correct design; a Staff engineer drives the session, finds the hard parts, and quantifies trade-offs; a Principal reframes the problem around the business outcome; an engineering manager adds staffing, sequencing, and operational ownership. §60 shows the full level table, example answers at each level, and adjacent tracks (SRE, data/ML, security, architects). It's in the playbook (Part VII) because it's easiest to use once Parts I–IV have given you the vocabulary.