How to get something out of this

The canvas rewards a specific habit, and it is the same habit that makes a system design interview go well: predict before you run. Look at the design, decide which component you think gives way first and at roughly what load, and only then press the button. Being wrong is the useful outcome — it is the moment a piece of intuition gets corrected, and it costs about a minute.

Then turn the traffic up. Not to a number you chose in advance, but slowly, watching the utilisation bars, until something goes red. That number is the design's capacity, and it is almost never the number the arithmetic suggested, because the arithmetic does not include queueing.

What the simulation actually does

Requests enter at a client and walk the graph. At each component they are served immediately if there is a free slot, wait if there is not, and are rejected if the queue is full. Service times are log-normal, so some requests are much slower than the median — which is what creates queues at loads well below capacity. Latency accumulates along the whole path, including the waiting, which is the part a boxes-and-arrows diagram cannot show.

A cache returns immediately on a hit and passes the miss downstream. A client with retries configured will re-send what fails, and if you have not given it jittered backoff, that amplification is real and will show up in the offered-load chart as a spike that arrives exactly when the system can least take it.

Things worth trying

• Run a design at its designed load, then at twice it. The failure is rarely proportional.
• Kill the database mid-run and watch how far the damage spreads. Then give the service a cache and do it again.
• Set a client to three retries with no backoff, then kill something. That is a retry storm inside your own drawing.
• Add replicas to whatever the bottleneck is until something else becomes the bottleneck. Every design has a next constraint, and knowing what it is is most of capacity planning.