intermediate · Interactive lab
Circuit Breaker
A retry asks whether to send this request again. A breaker asks whether anyone should be calling that dependency right now. Learn what its state means and how it gets back to normal.
By the end: Tell a breaker apart from a retry: one asks whether to send this request again, the other whether anyone should be calling that dependency at all.
Your challenge
Start here. This lab opens with the usual reflex, and it is wrong: every request is simply sent, whatever the breaker has counted. Some of those calls land on an API that is already failing, and one of them restores full traffic on no evidence. Read each moment, choose, and test.
See it happen
Watch the breaker decide
- Order Processing → Integration Logic
- Integration Logic → Warehouse API: calls, when the breaker allows
A breaker in front of one dependency
Integration Logic does not call the Warehouse API directly: every call goes through a circuit breaker. The breaker remembers what recent calls did. Watch its state, and what it allows.
Learn more
Why this pattern exists
Integration Logic calls the Warehouse API through a circuit breaker. The breaker does not look at the request in hand; it looks at what recent calls did. While it is CLOSED, calls go out as usual. When enough of them fail in a row, it goes OPEN and stops sending: the caller is answered at once instead of waiting for a timeout, and the Warehouse API is left alone to recover. After a cool-down the breaker allows one trial request — a probe — and that is the HALF-OPEN state: not recovered, only testing. Probes that come back let it close again; a probe that fails opens it once more and the cool-down starts over.
Order Processing sends requests through Integration Logic to the Warehouse API, with a circuit breaker between them. Each graded case is one moment: what the breaker had counted when a request arrived, and who was waiting for it. The breaker's policy is fixed here — three failures in a row open it, a 5 s cool-down, two probes back before full traffic.
- Tell a breaker apart from a retry: one asks whether to send this request again, the other whether anyone should be calling that dependency at all.
- Read a breaker's own state — failures counted, cool-down elapsed, probes returned — and say what it allows right now.
- Choose what happens to a request in each state without hammering a dependency that is down, restoring full traffic on one lucky call, or leaving a breaker open for ever.
The rule this lesson applies: Repeatedly calling a dependency that is failing costs twice: every caller waits for its own timeout, and the load keeps the dependency from recovering. A breaker converts that slow failure into a fast one and takes the load away. The price is that the caller stops learning: while the breaker is open, nothing knows whether the Warehouse API is well again. That is what the cool-down and the probe are for — a small, deliberate amount of traffic to find out. One probe that succeeds is evidence, not proof: this lesson's policy asks for two before full traffic returns, because a dependency that has just come up can fall over again under the whole load. Retry and breaker work together: retries handle a request that may still succeed; the breaker decides whether those retries should be leaving at all. A retry policy with no breaker in front of it is how a slow dependency turns into a queue of waiting callers.