Start here: from "one server" to designing systems with confidence
System design is the craft of deciding which parts a piece of software needs, how they talk to each other, and what happens when traffic grows or something breaks. You don't need to have built a big system to learn it. You need a clear picture of the building blocks, a handful of numbers, and lots of practice making and defending trade-offs. This page sets you up.
1. What system design is
Writing code answers "how does this function work?". System design answers bigger questions:
- What are the parts? Servers, databases, caches, queues, storage, and how requests flow between them.
- How big must each part be? Ten users and ten million users need very different designs. You'll learn to estimate which one you have.
- What happens when something fails? Machines crash, networks drop packets, whole data centres go dark. Good designs keep working, or fail gracefully.
- What did we give up? Every choice trades something: speed for freshness, simplicity for scale, cost for safety. Saying the trade-off out loud is the skill.
It's also a standard part of software interviews from mid-level up, and the most heavily weighted round at senior and above. This track teaches the real engineering first; interview technique (Module 05 and the worked designs) sits on top of it.
2. How this track teaches
- Six basics modules, then twenty-nine modules in five levels. Level 0 (B1–B6) teaches the vocabulary from zero: clients, servers, APIs, databases, and how an app grows from one server to millions of users. Then from how a single request travels (Level 1) to multi-region architecture and AI systems (Level 5). The module map shows them all.
- The same ten sections in every module: the idea, how it works, try it, trade-offs, in real systems, a memory hook, mistakes, a design exercise, a quiz, and further reading.
- Press Play on every visualizer. Watching a request hop between machines, or a replica fall behind, sticks better than reading about it. Inside a player, ← → step and space plays.
- Thirty-two worked designs put the modules together. Try each one on paper first, then compare: every deep dive shows a bad, a good and a great answer, and why.
- Hover or tap a dotted word for a one-line definition; they're all in the glossary below.
3. What you need
- Some programming experience. You should know what a function, an HTTP request and a database table are. You don't need to have run servers in production.
- Paper, or a free whiteboard tool such as Excalidraw or tldraw. Drawing boxes and arrows yourself is how designs become yours.
- Optional, from Level 3: Docker, to run PostgreSQL, Redis and Kafka on your laptop and watch the behaviour the modules describe.
- About 45 minutes a day, five days a week, for about six months (the 24-week roadmap).
4. The map of building blocks
Almost every system you'll design is assembled from the same dozen parts. The best way to meet them is to watch a system grow. Press Play: it starts as one server and adds one part each time a real problem appears.
| Block | What it does | Module |
|---|---|---|
| Client | The browser, phone app or other service that sends requests. | 01 |
| DNS | Turns a name (example.com) into the address of a server. | 01, 06 |
| Load balancer | Spreads requests across many identical servers; skips broken ones. | 08 |
| App servers | Run your code. Kept stateless so you can add or remove copies freely. | 08 |
| Database | The source of truth: stores data durably and answers queries. | 11–17 |
| Cache | Keeps hot data in memory so most reads skip the database. | 09 |
| Blob storage | Holds big files (images, video, backups) cheaply and durably. | 10 |
| CDN | Copies of content on servers near users, so far-away users get it fast. | 10 |
| Queue or log | Holds work to do later, so slow jobs don't block user requests. | 18 |
| Workers | Background processes that take work from the queue. | 18, 23 |
| Replicas and shards | Copies of data for safety and reads; splits of data for size and writes. | 14, 15 |
5. Five ideas that run through every design
1. Everything is a trade-off
There is no best database or best architecture, only the best fit for these requirements. Name what you gain and what you give up.
2. Numbers decide, not fashion
One modern server handles far more than most people guess. A quick estimate (Module 03) tells you whether you need sharding, or just an index.
3. Start simple, add parts for a reason
Every new box adds cost, failure modes and things to learn at 3 a.m. Add one only when a requirement or a number forces it.
4. Failure is normal
At scale, some disk, machine or network link is always broken. Design for it: redundancy, timeouts, retries, and work that's safe to repeat.
5. Data is the hard part
Servers are easy to add and replace. Data must be stored, copied, split and kept correct. Most deep dives are really about data.
…and say it out loud
A design nobody else understands isn't finished. Practise explaining each choice in one sentence: "I chose X because Y, and it costs Z."
6. The daily routine (45 minutes)
A fixed theme per day means you never waste time deciding what to study.
| Day | Theme | Output |
|---|---|---|
| Monday | Learn: read this week's module and run its visualizers | 3 bullet notes in your design notebook |
| Tuesday | Practise: redo the widget, then the design exercise on paper | A sketch with your numbers on it |
| Wednesday | Recall: draw the week's diagram or design from memory, then check it | The parts you forgot, circled |
| Thursday | Read: one real engineering write-up (a company blog post or a paper) on the topic | One thing real systems do differently |
| Friday | Explain: talk through the idea out loud for five minutes, or record yourself | A short note you'd be happy to reread in a year |
Optional weekend: try one of the worked designs on paper with a 45-minute timer, then compare with the answer.
7. Your design notebook
Keep one file or paper notebook, one entry per design you attempt. Use the same headings every time; they're the steps of the design method (Module 05):
## Design: URL shortener (2026-10-20, 45 min, attempt 1)
Requirements create short link; redirect; links don't expire · 100M new/month, 10:1 reads
Estimates ~40 writes/s, ~400 reads/s avg, ×3 peak · 6 TB over 10 years → one DB is fine
Entities/API Link(code, long_url, owner, created) · POST /links · GET /{code} → 302
Design client → LB → app → cache → Postgres; codes from a counter + base62
Deep dives hot links (cache + CDN), unique codes without collisions, analytics via a queue
Missed custom aliases; abuse (malware links); 301 vs 302 for analytics
Next time ask about expiry and analytics before drawingThe "Missed" line is the most valuable one: it's your personal list of gaps, and it shrinks visibly over the weeks.
8. Self-check quiz
Which component keeps hot data in memory so most reads skip the database?
Why are app servers kept stateless?
When should you add a new component to a design?
What decides whether you need sharding?
Where do most hard design problems really live?
9. Glossary
Every dotted word on the system design pages, in one place. New terms are added as each module is published.
10. Where to go next
New to backends? B1 →
Level 0 starts from zero: clients, servers, APIs and databases, then how an app grows to millions of users.
Module 01 →
How a request travels: every hop from typing a URL to seeing the page.
The roadmap →
24 weeks, with a concrete output every Friday.
Worked designs →
The 46 designs, and which modules each one needs.
Under the hood →
20 optional deep dives into how the technologies really work, product by product, with labs.
Review deck →
Spaced-repetition cards from every quiz and memory hook in the track.