Circuit Breaker

In technical terms

A three-state machine: closed (normal, failure budget tracked), open (calls rejected immediately, fallback runs), half-open (a few probe calls test recovery). Triggered by error-rate thresholds, consecutive failures, or latency budgets; implemented client-side (Resilience4j, Polly) or at the mesh layer (Envoy).

Why it appears in interviews

It is the standard probe of failure thinking: a slow dependency is more dangerous than a dead one because callers pile up waiting, exhausting threads, connections, and patience. Breakers turn a collapse into a degraded but alive system.

The common misconception

That the breaker recovers users’ experience. It only fails fast; the fallback (cached value, feature off, queued work) is what customers feel. A breaker without a designed fallback just changes the error message.

Trade-offs & when it hurts

Trips too eagerly: you shed healthy traffic while the dependency recovers; too late: retries have already piled up. Half-open probes must be concurrency-limited or the first successful probe lets a stampede re-open it. Mesh-level breakers react to symptoms your app-specific semantics would ignore, and vice versa.

How to show it in an interview

Never present a breaker without its fallback. Pair them in one sentence: “It opens on a 50% error rate over a 30-second window and serves the last cached price with a stale badge; half-open probes one request per ten seconds.” The cache-stale sentence is where senior points live.

Questions this concept earns

• The dependency is slow at 800ms but never errors: what should the breaker do about that?
• Half-open just let a probe through: what happens if 4,000 concurrent requests also just woke up?
• Your breaker opened during a 30-minute outage: what does the overall user experience look like?

Related