All topics
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

1
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.
2
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.
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "What problem does a circuit breaker solve?" *Probing:* the failure mode. *Stalls:* "Errors." *Moves up:* cascading failure — without it, calls to a dead dependency pile up, exhaust threads and take the caller down too.
1. "What problem does a circuit breaker solve?"
5
2. "What are the three states?" *Probing:* the mechanics. *Stalls:* "Open and closed." *Moves up:* closed passing traffic, open failing fast, half-open letting a trial request through to test recovery.
2. "What are the three states?"
6
3. "What should happen when the breaker is open?" *Probing:* the design. *Stalls:* "Return an error." *Moves up:* a defined fallback — cached data, a partial response, or a clear degraded message — decided by the business, not left to a stack trace.
3. "What should happen when the breaker is open?"
7
4. "What is the tuning risk?" *Probing:* experience. *Stalls:* "None." *Moves up:* a threshold too sensitive trips on normal variance and causes the outage it was meant to prevent.
4. "What is the tuning risk?"
Use cases:resiliencefail-fastresilience4jcascading-failure