A practitioner's guide to designing systems that scale and that the business actually needs, written as preparation for the system design loop at Google, Microsoft, Meta, Amazon, and other tier-1 companies, for every senior role: Senior, Staff, and Principal engineers; Engineering Managers, Senior EMs, and Directors; and adjacent senior tracks such as SRE, platform, data/ML, security, and solutions architecture.
Most system design material teaches you to draw boxes. Interviewers at senior levels have already seen ten thousand candidates draw the same load balancer → app servers → cache → database diagram. What they are actually scoring is whether you can:
- Start from a business outcome (revenue, retention, cost, risk, compliance) and turn it into measurable requirements (latency and reliability targets, durability, cost per transaction).
- Pick the architecture those requirements force, and say clearly what you are giving up for it.
- Go deep where it matters: the one or two components where the system will actually break.
- Think past launch day: failure modes, migration, cost growth, team ownership, how the system changes when traffic is 10× higher.
This guide builds those skills in order, starting from zero: each part assumes only the parts before it, and every forward reference is marked with the section where the idea is taught.
How the guide is organized
Part 0 Getting Started what system design is, plain-language glossary, how the interview
│ is scored, the step-by-step framework
Part I Beginner estimation, building blocks, APIs, storage, caching, scaling basics
│
Part II Intermediate sharding, replication & consistency, async messaging, distributed
│ transactions, service boundaries, reliability, specialized indexes,
│ observability, security, data modeling practice
Part III Advanced consensus & time, multi-region & cells, data platforms, performance
│ at extreme scale, verification, backup & restore, AI/ML, agentic AI
Part IV Expert business outcomes → architecture, cost engineering, migrations,
│ the leadership decision layer
Part V Casebook 16 interview problems solved compactly, easy → hard
│
Part VI Walkthroughs 12 full mock interviews with candidate–interviewer dialogue, easy → hard
│
Part VII Interview Playbook level calibration, company notes, communication, drawing designs
(whiteboard, paper, canvas, prototypes), the past-project round,
red flags, study plan, prompt bank, cheat sheets
Appendices real incidents decoded · engineering-blog & paper map
Short on time? Read §1–2, §14 (reliability), §27 (business outcomes → architecture), and three cases from Part V.
How each concept is presented. Most concept sections in Parts I–IV end with three recurring blocks, and every case in Part V carries the same three:
- 🏗️ Architecture / flow: an ASCII diagram of the components or the step-by-step request/data flow.
- 🌍 In production: how named companies (Google, Microsoft, Amazon, Meta, Netflix, Uber, Stripe, Slack, Discord, Shopify, Figma, and others) built it, taken from their engineering blogs and papers, with the lesson each one learned.
- ⚠️ Corner cases & deep details: the edge cases, internals, and failure modes that interviewers probe after you've drawn the happy path (expected at Staff and above; a strong differentiator at Senior).
Who this guide is for, and how to use it by role
Every senior loop uses the same building blocks. What changes by level is how far up the ladder of framing, depth, and ownership the interviewer expects you to climb. Read the parts in order; use this table to decide where to slow down:
| Target role | What the design round expects | Where to go deepest |
|---|---|---|
| Senior engineer (Google L5, Meta E5, Microsoft 63–64, Amazon SDE III / L6) | A complete, correct design; solid fundamentals; sensible trade-offs; able to go deep on 1–2 components when asked | Parts 0–II (incl. §18 data modeling), Part V cases, Part VI walkthroughs (Steps 0–6), §64 past project |
| Staff engineer (L6 / E6 / 65 / Principal L7 at Amazon) | Drives the session; finds the hard parts unprompted; quantifies trade-offs; failure modes, scale, evolution | All of the above + Part III (§19–26), the ⚠️ corner-case blocks, Appendix A |
| Principal / Senior Staff and above (L7+ / E7+ / 66–67+) | Reframes the problem around the business outcome; cost, migration, org, one-way doors | Everything, especially Part IV (§27–30), the strategic lens in each case, Appendices A–B |
| Engineering Manager / Sr. EM / Director | A credible architecture plus execution: staffing, sequencing, risk, operations, stakeholder alignment | §1–2, §14, §16, §20, Part IV (§27–30), the EM rows of §60, §64.7 |
| Adjacent senior tracks (SRE, platform, data/ML, security, architects, TPMs) | The same framework with a different emphasis | See §60.3 |
Wherever the guide compares levels (§1.3, §60, and the "signals by level" tables), find your target column and the one above it. Interviewers level you by the highest column you reach consistently, not occasionally.
Related guides in this wiki (this guide links to them rather than repeating them):
- Scale, load & performance testing: percentiles, Little's Law, fan-out math, load tools
- CDN guide (
cdn/real-life-cdn-guide.mdin the wiki; not yet on frontendlabs.xyz): edge caching, consistent hashing, multi-tier caches, multi-CDN - Security: authN/Z, TLS, threat modeling in depth
- Kubernetes & Docker: the compute substrate most designs end up on
- Data structures & algorithms: tries, heaps, consistent hashing, graphs used in §42, §43, §46
- AI/ML: background for §25