Prerequisites & Self-Assessment
The honest list of what you need before starting, plus a test to find out where you actually are.
Time to read: ~10 minutes (plus 20 for the assessment)
The short version
You need surprisingly little:
Required
- You can write and run a program in some language (Python, Java, JavaScript, C++, Go — any).
- You have seen a web application: a frontend that talks to a backend that talks to a database.
- You know what a function, a loop, an array, and a hash map are.
- You are comfortable in a terminal enough to run
curl, cd, and docker run.
Helpful but not required (this guide teaches all of it)
- SQL beyond
SELECT *
- What HTTP status codes mean
- Git
- Any exposure to Linux
- Big-O notation
Explicitly NOT required
- Industry experience
- Having worked at scale
- Knowing AWS/GCP
- A computer science degree
- Kubernetes, Kafka, Docker, or any specific tool
If you’re missing something in the “required” list, that’s fine — fix it first. Suggestions are at
the bottom of this page.
Self-assessment
Answer honestly. Nobody is watching. Write your answers down before checking — recognizing an
answer when you see it is worth nothing here.
Section A — Programming & Web Basics (5 questions)
A1. What happens, step by step, when you type google.com into a browser and press Enter?
Expect roughly: browser checks its cache → OS resolver / DNS lookup (recursive resolver → root →
TLD → authoritative) → gets an IP → TCP handshake (SYN/SYN-ACK/ACK) → TLS handshake → HTTP GET →
server responds → browser parses HTML, fetches CSS/JS/images → renders.
If you got "it looks up the IP and asks the server for the page" — that's a pass for now. This whole
chain is covered in [Networking 101](/system-design/01-foundations/02-networking-basics.html).
A2. What is the difference between a GET and a POST request?
GET retrieves data, has no body, is *safe* (no side effects) and *idempotent* (repeating it changes
nothing), and can be cached and bookmarked. POST submits data, has a body, is neither safe nor
idempotent by default (submit twice = two orders). The idempotency distinction becomes very
important later — see [Idempotency](/system-design/04-distributed-systems/11-idempotency.html).
A3. What's a hash map, and what's its average lookup time?
A key–value structure using a hash function to map keys to array slots. O(1) average lookup, O(n)
worst case with heavy collisions. Nearly every caching and sharding technique in this repo is a hash
map idea stretched across machines.
A4. In SQL, what does a JOIN do?
Combines rows from two tables based on a related column. `SELECT u.name, o.total FROM users u JOIN
orders o ON u.id = o.user_id`. Important later: joins are the thing you *lose* when you shard, which
is a large part of why NoSQL data modeling looks so different.
A5. Your program needs to read a 10 GB file but the machine has 8 GB of RAM. What do you do?
Stream it — read in chunks, process, discard. Don't load it all. If you said "read it line by line"
or "process in batches," you already have the instinct that most scaling techniques rely on.
Scoring: 4–5 → ready. 2–3 → start with Part 1 and go slowly. 0–1 → spend two weeks on the
prerequisites list below first.
Section B — Do you already know some system design? (5 questions)
B1. Why would you put a cache in front of a database?
Because reading from RAM is ~100,000× faster than a random disk read, and most workloads read the
same small set of data repeatedly. A cache absorbs read load so the database survives, and it cuts
p99 latency. Cost: staleness, invalidation complexity, and a new failure mode (cache down → database
gets 100% of traffic at once). → [Caching](/system-design/02-building-blocks/05-caching.html)
B2. What's the difference between vertical and horizontal scaling?
Vertical = bigger machine (more CPU/RAM). Simple, no code changes, but has a hard ceiling and a
single point of failure, and cost grows super-linearly. Horizontal = more machines. Effectively
unlimited and fault-tolerant, but forces statelessness, introduces coordination and network
failures, and makes your data problem harder. → [Scalability](/system-design/01-foundations/11-scalability.html)
B3. What does "eventual consistency" mean, and where have you seen it?
If writes stop, all replicas eventually converge to the same value — but for some window, different
readers see different values. You've seen it in: YouTube view counts, Instagram like counts, DNS
propagation, and S3 (historically). → [Consistency Models](/system-design/01-foundations/13-consistency-models.html)
B4. Roughly how many requests per second is 1 million requests per day?
1,000,000 / 86,400 ≈ **11.6 requests/second** average. Peak is typically 2–3× that, so ~25–35 RPS.
That's *small* — one modest server handles it. Most candidates wildly overestimate how much traffic
a big-sounding number represents. → [Back-of-the-Envelope](/system-design/01-foundations/09-back-of-envelope-estimation.html)
B5. Your API calls a third-party service that starts taking 30 seconds instead of 300 ms. What happens to your system, and what should you have built?
Your threads/connections pile up waiting, your pool exhausts, and *your whole API* goes down —
including endpoints that don't use that service at all. This is cascading failure. You should have
had: an aggressive timeout, a circuit breaker to fail fast after N failures, a bulkhead so that
dependency can only consume a fraction of your resources, and a graceful degradation path.
→ [Resilience Patterns](/system-design/04-distributed-systems/13-resilience-patterns.html)
Scoring:
- 0–1: Perfect. This guide was written for you. Standard or Deep track.
- 2–3: You have scattered knowledge. Standard track, but you can skim Part 1.
- 4–5: Sprint track. Focus on Part 11 and case studies — your gap
is probably structure and depth, not concepts.
You don’t need much, and everything is free.
| Tool |
Why |
Install |
| Docker Desktop |
Run Postgres/Redis/Kafka in one command instead of installing them |
docker.com |
| curl |
Poke at HTTP directly |
Pre-installed on macOS/Linux; on Windows use WSL |
| A terminal |
Everything |
macOS: Terminal/iTerm. Windows: install WSL2 — genuinely worth it. |
| Excalidraw |
Draw architecture diagrams |
excalidraw.com, nothing to install |
| A code editor |
VS Code is fine |
code.visualstudio.com |
Optional but useful: dig (DNS), httpie (nicer curl), k6 or wrk (load testing), psql.
Sanity check — this should print a Postgres version:
docker run --rm postgres:16 postgres --version
Filling gaps in the “required” list
If you can’t program yet. Stop here and do that first, for real. System design without coding
ability is trivia. Pick Python, spend 6–8 weeks on
CS50 or Python Crash Course,
and build three small things. Then come back.
If you’ve never built a web app. Build one before Week 4. It doesn’t have to be good:
A “notes” app. Backend with 4 endpoints (create, list, update, delete). A real database
(Postgres in Docker). A frontend or just Postman. Deploy it somewhere free (Railway, Render,
Fly.io) so it’s on the internet.
That single project makes half of this guide concrete instead of abstract.
If SQL is weak. SQLBolt — about 3 hours, interactive, free. Enough for
this entire guide.
If Linux/terminal is weak. MIT Missing Semester lectures 1–4.
If Big-O is fuzzy. You need only the intuition: O(1) = instant, O(log n) = fine, O(n) = scales
with data, O(n²) = will kill you. That’s genuinely enough for design interviews. (For coding
interviews you need more, but that’s a different repo.)
What about the coding interview?
Design interviews are one round in a loop that also includes coding (DSA), and often behavioral.
This repo covers design and touches on behavioral
(here).
Do not let design prep replace coding prep. For most junior and mid-level roles, coding rounds
eliminate more candidates than design rounds do. Budget accordingly — roughly 60/40 coding-to-design
for junior roles, 50/50 for mid, and 40/60 for senior.
Next
→ The Interview Formats You’ll Face
→ Glossary — bookmark it, you’ll come back constantly
→ ROADMAP.md — pick your track and start Week 1