Explain Circuit Breakers in Microservices

4 / 12

resilience

Circuit Breakers

Stop hammering a failing downstream — fail fast for a window — so a slow dependency doesn't cascade into your own outage.

In a distributed system, the most dangerous failures are not isolated — they cascade. When a downstream service becomes slow or unavailable, every caller's requests pile up waiting on it, exhausting their thread pools and connections, so the callers fail too, and the outage spreads upstream until the whole system is down. The circuit breaker is the pattern that stops this chain reaction by failing fast against a dependency that is clearly broken, giving it room to recover instead of being hammered while it is down.

An electrical circuit breaker: when current surges dangerously it trips and cuts the circuit, protecting the whole house instead of letting one fault start a fire.

Key Concepts

It works like an electrical circuit breaker and has three states. In the closed state, calls flow through normally while the breaker counts failures. When failures cross a threshold (a percentage or count within a window), it trips to open: for a cooldown period every call is rejected immediately without even attempting the downstream, so the caller fails fast and the struggling service gets a break. After the cooldown the breaker moves to half-open and lets a few trial requests through; if they succeed it closes again and normal traffic resumes, and if they fail it re-opens for another cooldown. The fast rejection while open is the whole point — it frees the caller's resources and prevents the thread-pool exhaustion that would otherwise propagate the failure. Pairing the breaker with a fallback (a cached value, a default, or a graceful degraded response) turns a hard error into a softer one.

The essentials interviewers probe are the three states and their transitions, tuning the thresholds and cooldown sensibly (too sensitive trips on normal blips, too lax lets damage accumulate), and combining the breaker with timeouts, retries, and bulkheads as a layered resilience strategy. Libraries like Resilience4j (and historically Hystrix) implement this, and on a service mesh the breaker can live in the sidecar. The conceptual takeaway is that failing fast is sometimes the most reliable thing a system can do.