Skip to content

00. System Design First Principles — The Five-Year-Old Version

Before drawing boxes and arrows, learn how to think about systems that serve millions.

Imagine you are opening a restaurant.

Not a food cart. A proper restaurant — one that needs to serve hundreds of people every evening without anyone waiting too long, getting the wrong dish, or leaving hungry.

Before you pick paint colors or buy fancy plates, you need to answer some basic questions. How many customers will come? What will the menu look like — ten dishes or two hundred? How big should the kitchen be? Do you need one chef or five prep stations — one for salads, one for grills, one for desserts?

What happens when the Friday rush hits and every table is full? You need a waiting line — a queue at the door that holds people without losing them. What if a chef calls in sick? The grills still need to work. What if a supplier delivers the wrong ingredients? The house rules say you never serve raw chicken, no matter what.

Now zoom out. Every tech system is a restaurant.

Twitter is a restaurant where 500 million order tickets arrive daily. Each tweet is an order. The kitchen — thousands of servers — processes, stores, and fans out each tweet to followers. The menu is the API: post a tweet, read a timeline, search. The waiting line is Kafka, absorbing write spikes. Each prep station is a microservice: timeline service, notification service, search indexer. The house rules say timelines must load in under 200ms and nothing gets lost.

System design is the same thing at every company. You are building a restaurant for requests instead of people. The scale changes. The physics stays.

This module teaches you how to think — before you learn specific tools. First principles. The mental models that make every system design conversation structured, not chaotic. We start with what interviewers actually want. Then requirements. Then numbers. Then components. Then the hard tradeoffs — consistency, failure, latency. By the end, you will have a framework for any design question, not memorized answers for specific ones.

A tiny worked example

Say someone asks: "Design a URL shortener." Before drawing a single box:

house rules (requirements)
  │
  ├── functional: shorten URL, redirect, analytics?
  ├── non-functional: 100M URLs/month, <50ms redirect, 99.9% uptime
  │
  ▼
back-of-envelope (order tickets per second)
  │
  ├── writes: 100M/month ÷ 30 ÷ 86400 ≈ 40 writes/sec
  ├── reads: 100:1 read/write → 4,000 reads/sec
  ├── storage: 100M × 1KB ≈ 100GB/year
  │
  ▼
building blocks
  │
  ├── kitchen: app servers (stateless)
  ├── prep station 1: key generation service
  ├── prep station 2: database (reads >> writes → cache-friendly)
  ├── waiting line: not needed yet (40 writes/sec is small)
  │
  ▼
first design on whiteboard

See. No magic. Requirements → numbers → components → tradeoffs. Every system design follows this arc.

The placeholders you will see called back

Every topic file in this module calls back to these restaurant terms. They are the shared vocabulary that ties 14 lessons into one story.

Placeholder Meaning
restaurant the complete system you are designing — all components working together
kitchen the backend — servers, compute, processing logic that does the real work
order ticket a single user request flowing through the system end to end
menu the API or interface — what users can ask for and how they ask for it
waiting line a queue that absorbs traffic spikes so nothing gets dropped
prep station an individual service or component, each doing one job well
house rules the requirements and constraints — latency SLAs, uptime targets, consistency guarantees

Top resources

What's coming

  1. 01-what-interviewers-actually-evaluate.md — The real signal: structured thinking, not a perfect architecture
  2. 02-requirements-before-boxes.md — Functional vs non-functional. Scope the problem before touching the whiteboard.
  3. 03-back-of-envelope-math.md — QPS, storage, bandwidth — capacity estimation with real numbers
  4. 04-single-box-to-breakdown.md — One server works, then it doesn't. Why a single machine fails.
  5. 05-building-blocks-toolkit.md — The 8 components every system uses: LB, cache, DB, queue, CDN, and more
  6. 06-data-flow-first-design.md — Follow the data. Write path vs read path. One request, end to end.
  7. 07-storage-decision-framework.md — SQL vs NoSQL is not a religion. A decision framework.
  8. 08-caching-where-and-why.md — Cache at the right layer. Invalidation. The only two hard problems.
  9. 09-scaling-dimensions.md — Vertical, horizontal, stateless, sharding. When each applies.
  10. 10-cap-theorem-reality.md — What CAP actually means. Not what the textbook says.
  11. 11-failure-modes-and-resilience.md — Everything fails. Circuit breakers, retries, bulkheads.
  12. 12-latency-and-throughput-budgets.md — P50, P99, latency waterfall. How to set and meet SLA budgets.
  13. 13-structured-walkthrough.md — The 4-step interview framework. How to communicate tradeoffs.
  14. 14-honest-admission.md — What's genuinely hard. Where experts disagree. What we don't know.

Bridge. You know the restaurant needs to work. But what does "work" mean to the interviewer? The first thing to understand is what signal they're looking for. → 01-what-interviewers-actually-evaluate.md