Everything holds
until it doesn't.
New to system design? The Basics track walks you through building one bus-tracking app, lesson by lesson, from a single server to caches, replicas, shards and queues. Then take on Real World briefs with nobody holding your hand. The simulation is deterministic: the same build fails the same way every time, so you can learn from it.
No account needed for the first chapter · no card · retries always unlimited
Four answers to the same brief
A URL shortener that has to carry a million users. Here is what each build actually sustains before it starts dropping requests — measured by the engine, not asserted by us.
One box, no cache
the database is the constraint
Split the compute
more servers, same bottleneck
Cache in front of it
fix the actual constraint
Split + cache
read path and write path apart
Note the second row. Doubling the compute changes nothing while the database is the thing that is saturated — and the leaderboard ranks throughput per dollar, so paying for it costs you twice.
Nothing tells you the traffic mix
A shortener is overwhelmingly reads. Working that out — and realising the read path is what has to scale — is the exercise. Print it on the brief and there is nothing left to solve.
Your API is yours to design
You declare the endpoints and bind them onto compute, many to many. Put the read flood and the write path on one box and watch the valuable traffic starve first.
Scores are computed server-side
Your browser animates the run. The server re-runs the identical simulation and records what it gets. That is the only reason a leaderboard here is worth reading.
Find out where your design breaks.
The Basics track is free, and its first chapter needs no account.