A server dies. What happens to the one left standing?
Two app servers share the traffic, each at about 43% CPU. At second 60, app-2 crashes. Pick what you think happens to app-1, then watch the recording decide.
From the recording: app-1 goes from 65 → 130 rps and reaches 100% CPU by second 63. Two servers at 43% looked comfortable; one server at double the load is not.
The recorded run · Lose an app server
You just did it. That's every challenge.
You guessed, the system ran, and the recording showed you why. Each challenge is that loop, on a different system.
Predict
Before anything runs, say what you think will happen. Being wrong is useful.
Run
The system plays 90 recorded seconds of real traffic, with its faults on schedule.
Understand
See what happened in order, with the number behind each step, and where it differed from your guess.
Ten challenges, from your first API to scaling safely.
Follow the cable from the top. Each stop is a real system with a recorded run.
First production API
Put a small API online behind a load balancer and keep it healthy under steady traffic.
Load balancingSecure the edge
An inherited design works, but exposes more than it should. Close the gaps without breaking it.
Network exposureLose an app server
One of two app servers crashes under steady traffic. Keep the rest of the system out of saturation.
Redundancy · saturationCache matters
A read-heavy API overwhelms its database. Relieve it without buying the biggest instance.
CachingHeadroom under CPU pressure
A CPU spike lands on app-2 for 20 seconds. Leave enough headroom to stay out of saturation.
HeadroomWrite-heavy workload
Most traffic writes data. Find out what a cache can and cannot do for you.
Reads vs writesWhen the cache fails
The cache crashes, and the database has to cope on its own.
Dependency failureAfter the cache returns
The fault ends, but the system doesn't snap back. Watch what recovers, and when.
RecoverySurvive the peak
Traffic doubles in short bursts. The evaluation lands inside one of them.
Burst trafficScale out safely
More app servers should help, until each one opens its own database connections.
Connection limitsThe ideas behind every system design question.
Tap a card. Each idea is taught by a challenge where you watch it happen.
Answer “what happens when it fails?” with something you've seen.
Your service runs on two app servers behind a load balancer. One dies at peak. What happens?
The survivor takes all of it. In the run I watched, it went from 65 to 130 requests a second in one second, and hit 100% CPU by second 63.
So how would you size it?
For one server down, not for the average. Each server needs room for the whole load, or I add a third so the survivors share it.
Nothing on the screen is made up.
Recorded, second by second
Load, CPU, memory and health come from the run itself, for every part and every second.
Unknown is never zero
If something wasn't measured, you'll see “unknown”, never a calm flat line.
The same run every time
Traffic and faults replay exactly, so you can change one thing and compare.
What learners ask first.
Do I need to know distributed systems already?
No. The starter challenges assume you know what a server and a database are. Each challenge explains the ideas it uses.
Is it a game or a real system?
A simulation of a real system. Every part behaves the way the real one does under load, and every number is recorded from the run.
What if my prediction is wrong?
That's the point. Your guess is kept separate from the result, so you see exactly where your picture of the system was off.
How long does a challenge take?
Each run is 90 recorded seconds. Most people spend a few minutes predicting, running and reviewing.
What does it cost?
It is free during early access.