Why circuit breaker?
A flaky downstream service and a shared connection pool. Watch what happens when every caller waits out the timeout versus when a breaker fails fast.
Watch it explained
~27s animated walkthrough: a hung downstream call exhausting a connection pool vs. a breaker failing fast.
Loading player…
Service A → Service B
Every request goes straight to the downstream service and holds a slot for the full duration, success or failure.
sent
0
succeeded
0
pool rejected
0
avg latency
—
Closed
Open
Half-Open
Connection pool0 / 10 slots held
succeeding waiting on a timeout half-open trial free
pool utilization
0%
timed-out waits
0
fast-failed
0
Last events
Run traffic to see breaker decisions.
Why this matters
- Failures are expensive precisely because they're slow. A failing call still holds a pool slot for the full timeout — often longer than a successful call.
- A full pool fails everyone, not just the doomed calls. Turn the breaker off and crank the failure rate — watch "pool rejected" climb even though some requests would have succeeded.
- Failing fast is a feature. With the breaker on, a fast-failed request costs ~0ms instead of the full timeout, and the half-open probe checks recovery without risking the whole pool.
Downstream console
Make Service B flaky and watch the pool.
Try this
Set failure rate to 70%+ and run traffic. The pool fills with red (timed-out) slots and stays full — watch “pool rejected” start climbing. Then flip the breaker on and rerun with the same settings.