In distributed systems, a failed service can bring down the entire platform. The Circuit Breaker pattern is inspired by electrical circuit breakers: it cuts the circuit when something is failing, preventing the problem from spreading.
The three states
Closed
All calls pass through normally. The circuit monitors for failures.
Open
Calls are blocked immediately. The service returns error or fallback without attempting the call.
Half-Open
It allows a few test calls. If they succeed, it closes. If they fail, it opens again.
Why implement it?
- Prevents cascading failures: a slow service doesn't drag down the rest.
- Frees resources: threads don't stay blocked waiting for timeouts.
- Faster recovery: the failed service can recover without being overwhelmed.
- Better user experience: quick response with fallback instead of hanging.
Key configurations
- Failure threshold: how many errors before opening (e.g., 50% in 10 calls).
- Wait time: how long it stays open before trying again (e.g., 30 seconds).
- Test calls: how many calls to allow in half-open state.
- Fallback: what to return when the circuit is open.
Popular implementations
There are robust implementations in most languages: Resilience4j for Java, Polly for .NET, Hystrix (in maintenance) for Java, and patterns built into service meshes like Istio and Linkerd.
A Circuit Breaker is useless without observability. You need to see when circuits open, how long they stay open, and how often they trip.
