Everything holds
until it doesn't.
Design a system for a real product brief. Declare the API it needs, wire your routes onto compute, then watch traffic climb until something gives. The simulation is deterministic — the same build fails the same way every time, so you can actually learn from it.
Three levels free · 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.
First three levels are free.