Topic 3
Circuit breakers
A fallback only helps if you reach it quickly. If every request first waits for the dead primary to time out, each user pays the full timeout before the fallback even starts.
Predict first
Scroll sideways to see the whole diagram
Martin Fowler's circuit breaker wraps a remote call and counts its failures.
Text version
- Martin Fowler's circuit breaker wraps a remote call and counts its failures.
- When failures reach a threshold, it trips: further calls return an error immediately, without reaching the failing service, so a fallback can answer at once.
- After a timeout, it lets one trial call through to see whether the problem is fixed.
- If the trial succeeds, the breaker resets; if not, it opens again.
- Fowler's reasons: without it, callers tie up resources waiting on timeouts, failures cascade across systems, and the struggling service keeps getting hit.
Martin Fowler's "CircuitBreaker" (2014) describes the pattern. A breaker wraps the call and counts failures. Once they reach a threshold, it trips: further calls fail immediately without reaching the failing service, so the fallback answers at once. After a timeout it lets one trial call through; success resets it, failure opens it again.
100 requests while the primary is down
Illustrative · one request per second · 10 s timeout · trips after 5 failures · 30 s before a trial request
Calls to the dead primary
100
Total time users waited on it
1,000 s
With a breaker that trips after 5 failures and tries again every 30 seconds, the primary gets 8 calls instead of 100, and users wait 80 seconds in total instead of 1,000. The struggling service also gets far less traffic while it recovers, which is Fowler's other reason for the pattern: without it, one unresponsive service can tie up resources and spread failure to everything that calls it.
Put breakers where the gateway calls each model, so every application behind the gateway benefits.
Quick check