A system design course
Learn system design from one server up.
Grow one app, Chirp, from a laptop to fifty million users. Every lesson starts with something that broke, and works out why, with real numbers and diagrams you can play with.
- Course
System design, from one server up
37 lessons in 8 parts. Grow Chirp from a laptop to 50M users, with a simulation where early choices come back.
Start lesson 1.1 → - Interview practice New
Mock interviews with a whiteboard
URL shortener, rate limiter and more. Clarify, scope, estimate and draw, then compare each stage with a reference answer.
Open the questions → - Engineering blogs New
How real systems broke, and what they learned
Famous outages retold in plain words, with timelines, diagrams and the lessons behind them.
Read the posts → - Low-level design New
Classes, patterns and concurrency
SOLID and design patterns first, then parking lots, LRU caches and elevators, with class diagrams and code.
Start with the concepts →
One path, in order
Each lesson builds only on the ones before it. Nothing assumes a topic you haven't reached yet.
Decisions with consequences
Each part ends in the simulation. Choices you make early come back when Chirp grows.
All the way down
Real numbers, the edge cases, how it fails, and what interviewers ask next.
All lessons
-
1K users
Part 1One server, one database
Ends with Stage 0: MVP
-
100K users
Part 2More users than one server can handle
Ends with Stage 1: Growth
-
2M users
Part 3Choosing how to store data
Ends with Stage 2: New features
-
20M users
Part 4Doing work in the background
Ends with Stage 3: The celebrity
-
50M users
Part 5Splitting data across machines
Ends with Stage 4: Global
-
50M users, every day
Part 6Keeping it running
Ends with Epilogue: Incident day
-
New apps
Part 7New problems
Ends with Chat, ride-sharing, payments, video
-
After the course
Part 8Interview playbook
Ends with Practice
About System Design Road
A free place to learn system design properly, from one server up, and to practise the interviews that test it.
Why this exists
Most system design material falls into one of two traps. It either lists components (load balancer, cache, queue) without saying why any of them is there, or it shows a finished architecture for a famous company and leaves you to guess how anyone got there.
Real systems don't arrive finished. They start small and break in specific ways as they grow, and each piece exists because something went wrong without it. System Design Road teaches it in that order. You follow one made-up app, Chirp, from two founders and one rented server to fifty million users, and every lesson starts with the thing that broke.
What's here
- The course: 37 lessons in eight parts, from what happens when you open an app to consensus, multi-region and payments. Every lesson has real numbers and diagrams you can interact with.
- The simulation: run Chirp yourself. Make the design decisions at each stage, then watch real traffic test them. Early choices come back later.
- Interview practice: ten classic system design questions, practised stage by stage the way a real 45-minute round runs, each with a full walkthrough.
- Low-level design: object-oriented design, SOLID, the classic design patterns and concurrency, then ten LLD interview problems. The parking lot, LRU cache, Splitwise, chess and more, with Java code that compiles and outputs that come from real runs.
- Engineering blogs: well-known outages retold in plain words, with what the engineers learned and the lessons behind them.
How it's made
Three rules run through everything here:
- Explain why, not just what. Every component, pattern and class appears because a requirement or a failure needs it.
- Use real numbers. Estimates are worked through, latencies are realistic, and every code output on the site comes from actually running the code.
- Plain words. If a technical term is needed, it's explained the first time it appears.
Chirp, its founders and its users are fictional. The technology, the numbers and the outages in the blog are real, and each blog post links to the original report it retells.
It's free
Everything you can read here is free, and your progress, notes and whiteboards are saved in your own browser. Nothing is stored about you on a server. The privacy page has the details.
Found a mistake?
Corrections make the site better for everyone. If a number looks wrong, a diagram is unclear, or an explanation skips a step, please let us know.
Privacy
Short version: there are no accounts, no cookies, and no ads. Your progress stays in your own browser.
What stays on your device
Your progress through lessons, your practice answers, whiteboards, notes and reading settings are saved in your browser's local storage. They never leave your device and we can't see them. Clearing your browser's site data deletes them.
Visitor statistics
We use Cloudflare Web Analytics to count visits: which pages are read, roughly where visitors come from (for example a search engine or a link on another site), the country, the type of device, and how fast pages load. It doesn't use cookies, doesn't build a profile of you, and doesn't track you across other websites. The numbers are only ever seen in aggregate.
Services the site relies on
- Hosting. The site is served by Netlify, which, like any web host, processes your IP address to deliver pages and may keep short-lived server logs for security and reliability.
- Fonts. Typefaces are loaded from Google Fonts, so your browser contacts Google's servers to download them.
- Statistics. Cloudflare, as described above.
Each provider handles that data under its own privacy policy.
What we don't do
- No accounts, no sign-in, no passwords.
- No advertising, no ad trackers, no selling of data.
- No email collection on the site at the moment. If that changes, this page will say what's collected and why before it starts.
Changes
If this policy changes, the updated version will appear on this page with a new date.
Last updated: 12 November 2026.
404
That page isn't here.
The link may be old, or the address mistyped. Here are good places to start.
Engineering blogs
How real systems broke, and what their engineers learned.
The latest outages of 2026 and the landmark ones everyone still talks about, retold in plain words from the companies’ own write-ups. Each one has a timeline, diagrams of what actually happened, the lessons behind it, and a link to the original.
8 posts. Retold in our own words; the companies' originals are linked from every post.
- CloudflareLatestFebruary 2026
An empty query parameter withdrew a quarter of Cloudflare's customer IP ranges
A new clean-up task asked for "prefixes pending delete" but sent the flag with no value. The API read that as "all prefixes", and the task began removing customers' addresses from the internet.
Outage · 4 min read - ClerkLatestFebruary 2026
Clerk's sign-ins failed because Postgres guessed wrong about one column
A routine automatic statistics refresh sampled a column that was almost always empty, concluded it was always empty, and changed how a hot query ran. Over 95% of sign-in traffic was rejected.
Outage · 4 min read - AWSLandmarkOctober 2025
The race condition that emptied DynamoDB's address, and half the internet with it
Two copies of DynamoDB's DNS automation raced each other. One applied an old plan, the other deleted it, and DynamoDB's address in us-east-1 pointed nowhere. Apps around the world went down, and EC2 took until the afternoon to recover.
Outage · 4 min read - CrowdStrikeLandmarkJuly 2024
CrowdStrike and the 21st field: the biggest IT outage in history
A routine security content update told millions of Windows PCs to read a 21st field from a list that only had 20. The code ran inside the operating system's kernel, so every one of them crashed, again and again.
Outage · 4 min read - RobloxLandmarkOctober 2021
Roblox was down for 73 hours. Two hidden bugs, and blind monitoring.
Millions of players locked out for three days. The cause sat deep inside Consul, the system everything else used to find each other, and the monitoring that should have pointed to it depended on the same system.
Outage · 5 min read - SlackJanuary 2021
Slack's first workday of 2021, and the autoscaler that read the wrong signal
Everyone came back from the holidays on the same morning. A network hub couldn't keep up, servers looked idle while they waited, and the autoscaler removed capacity at exactly the wrong moment.
Outage · 4 min read - CloudflareNovember 2020
Cloudflare, a half-broken switch, and a six-hour outage
A network switch failed for six minutes, but only partly. The machines it connected disagreed about who could reach whom, a database failover kicked in, and a hidden bug turned six minutes into six and a half hours.
Outage · 4 min read - GitLabLandmarkJanuary 2017
GitLab deleted its production database, and found its backups didn't work
A tired engineer, a late night, and a command run on the wrong server. Then the real shock: of five ways to restore the data, almost none worked. GitLab livestreamed the recovery.
Outage · 5 min read