Build It. Break It.
See why a website slows down—and what helps it recover. Try a miniature cloud system without touching any real infrastructure.
- Run the simulation and watch requests move.
- Try Traffic spike to see where they back up.
- Add workers, then choose Recover system to clear the disruption.
Ready. Runs pause after 120 simulated seconds.
- Incoming
- 100req/s
- Completed
- 0req/s
- Waiting
- 0requests
- Dropped
- 0total
- Est. response
- —ms
Now, break it.
Recovery restores normal conditions. The backlog still needs to drain.
Find the pressure point
The system has room to breathe.
How the simulation works
This is a deterministic teaching model, not a benchmark or cloud sizing recommendation. Requests are interchangeable reads. All requests use a worker; cache hits skip the shared database. Replica regions add worker capacity but share one database.
Capacity = min(healthy workers × 35, database reads/sec ÷ cache-miss share). Each simulated second, requests are served up to capacity, overflow enters the bounded queue, and any remaining overflow is dropped. Waiting requests are served first. Response time is a service-time estimate plus average queue wait; it is not a measured percentile.
Cache warming, writes, network variation, retries, regional routing, and replication consistency are outside this model. One scenario is active at a time. Motion pauses offscreen and when the tab is hidden. Reduced-motion mode keeps the metrics live without moving particles.