What you are looking at

Users call checkout-svc, which calls payments-api. The API can handle about twelve calls at once; past that it slows down, and the slower it gets the more calls pile up. Every call has a one-second client timeout — and when the client gives up, the API does not know: it keeps working on the abandoned call (the hollow dots), burning capacity nobody will ever use.

Why retries can make an outage worse

Retrying immediately feels like resilience, but when the API is failing because it is overloaded, every retry is more load. With three immediate retries the API can see two to three times your real traffic exactly when it can least afford it — the “Load on API” number. Exponential backoff with full jitter spreads retries out so they stop arriving in synchronised waves, but it cannot turn a dead dependency into a live one.

What the breaker actually does

The breaker counts the outcomes of the last twenty calls. When at least half of them failed or timed out, itopens: calls are answered immediately with a fallback (a cached or degraded response) instead of waiting a second to fail, and the API gets room to recover. After a cooldown it goes half-open and lets three probe calls through; if they succeed it closes, if one fails it opens again. This is the same shape as resilience4j, Polly or opossum — a failing dependency should cost you milliseconds, not threads.

The numbers are a model, not a benchmark, and the whole thing runs 2.5× slower than real time so the dots are visible. The trade-off is real though: a breaker that opens too eagerly serves fallbacks to users who would have been fine, which is why the threshold, the window size and a meaningful fallback matter as much as the pattern.