The core idea
When you write code, you decide how one program works: its functions, its classes, its data structures. System design is one level up. You decide which programs exist, where each one runs, where the data lives, and how they talk to each other, so that the whole thing does its job for the number of people using it.
A design is a set of answers to questions like:
- Where is the data stored, and how many copies are there?
- What happens when one machine dies in the middle of a request?
- Which parts get slow first when traffic grows ten times, and what do we do about it?
- What does all of this cost to run, and who has to keep it running?
Meet Snip
Throughout this course we'll design one system and grow it: Snip, a link shortener. You paste a long URL and
get back a short one like snip.link/x7Kp. Anyone who opens the short link is sent on to the long one.
On day one, Snip is one program and one database on one machine:
Text version
- Inside One server: Snip app, Database
- Browser → Snip app: GET /x7Kp
- Snip app → Database: look up
That's a perfectly good design for a few thousand users. The rest of the course is about what you change, and why, as Snip gets more users, more data and stricter promises to keep.
What changes as a system grows
Small systems and large ones fail in different ways. As Snip grows, four things change:
| What grows | What it forces you to think about |
|---|---|
| Traffic | One machine can't serve every request, so you need more machines and a way to spread work across them. |
| Data | It no longer fits on one disk, or one database can't keep up, so you split it or copy it. |
| Failures | With hundreds of machines, something is always broken. The design has to keep working anyway. |
| People | Many teams work on the system at once, so its parts need clear boundaries and contracts. |
None of these are problems on day one. A good designer adds each piece of machinery when a real need appears, and can say what that need is. You'll see this in 01.08 When not to add infrastructure.
What interviews test
A system design interview is usually 45 to 60 minutes. You get a vague prompt ("design a link shortener") and a whiteboard. There's no single right answer, and the interviewer knows that. They're watching how you think:
| They're listening for | What it looks like |
|---|---|
| Clarifying the problem | You ask what the system must do and how big it is before drawing anything. |
| A design that works | Your boxes and arrows actually serve the main use cases, end to end. |
| Depth where it matters | You can go into detail on the hard parts: the data model, the busiest path, what breaks first. |
| Trade-offs | You say what each choice costs, not just what it buys, and why it fits these requirements. |
| Communication | You think out loud, keep the interviewer with you, and adjust when they push back. |
The bar rises with seniority. A junior candidate is expected to reach a working design with some guidance; a senior one is expected to drive the conversation and pick the deep dives themselves. Every design lesson in this course ends with what's expected at each level.
Two candidates design the same system. One names more technologies (Kafka, Cassandra, Kubernetes). The other uses fewer parts but explains why each is there and what it costs. Who usually does better?
How this course is built
The course follows the way people actually get good at this:
- Part 1 gives you the approach: requirements, the numbers to know, estimation, trade-offs and one framework you'll use for every design.
- Part 2 teaches the building blocks one at a time: caches, queues, replication, sharding and the rest. Each starts from a system that breaks without it and ends with real companies that use it.
- Part 3 applies the framework to 22 classic designs. You try each one yourself first, then compare.
- Part 4 reads real case studies from the companies' own write-ups.
Snip runs through all of it, picking up a cache, a load balancer, a queue and more as each one becomes necessary.
Recap
Interview questions
How do you approach a system design question you've never seen before?