Circuit Breaker — 3 States
The Question
What is the circuit breaker pattern and what are its three states?
What a Strong Answer Covers
- All three states. Half-open = single probe.
Senior-Level Answer
The circuit breaker pattern is a fault-tolerance mechanism that prevents a service from repeatedly calling a dependency that is failing or slow, which would otherwise waste resources, increase latency, and propagate failures upstream. The name comes from electrical circuit breakers: when current exceeds a safe threshold, the breaker trips to protect the circuit.
A circuit breaker wraps calls to an external dependency (database, third-party API, microservice) and tracks the outcome of recent calls. Based on failure rate or count, it transitions through three states:
**Closed (normal operation)**: All calls pass through to the dependency. The breaker counts failures in a rolling window (e.g., last 10 calls or last 60 seconds). If the failure rate exceeds a threshold (e.g., 50%), the breaker **trips** to Open.
**Open (failing fast)**: All calls are immediately rejected without contacting the dependency — they fail fast with a fallback response (cached data, default value, error to client). A timer starts. This prevents thread-pool exhaustion and gives the dependency time to recover. After the timeout (e.g., 30 seconds), the breaker transitions to Half-Open.
**Half-Open (probing for recovery)**: A limited number of probe requests are allowed through to the dependency. If the probes succeed (failure rate drops below threshold), the breaker resets to Closed. If probes fail, it immediately trips back to Open and restarts the timer. This prevents premature recovery that would immediately overload a struggling service.
Two failure metrics are commonly used: **count-based** (trip after N consecutive failures) and **rate-based** (trip when failure % exceeds threshold within a time window). Rate-based is generally more accurate under variable traffic — high failure counts in absolute terms may represent a low failure rate during peak traffic.
Fallback strategies: return a cached response, return a default/empty response, queue the request for later processing, or return a user-visible error with appropriate messaging ("Service temporarily unavailable").
In practice: libraries like Hystrix (deprecated), Resilience4j (JVM), Polly (.NET), and PyBreaker implement this pattern. Service meshes like Istio implement circuit breaking at the infrastructure layer, removing the need for application-level instrumentation. Key configuration parameters: failure threshold, time window, open-state timeout, half-open probe count.
What Separates a 2/3 from a 3/3
2/3 — Passing but Incomplete
Correctly describes all three states and their transitions, explains the core problem (cascading failures / thread exhaustion), and names at least one fallback strategy.
3/3 — Strong Answer
Distinguishes count-based vs. rate-based failure metrics, explains the purpose of Half-Open probing (preventing thundering herd on recovery), names specific libraries or service mesh implementations, and discusses fallback design.
Common Mistakes
- Describing only two states (open/closed) and forgetting Half-Open, which is the mechanism that prevents oscillation.
- Not explaining WHY open-state failing-fast is better than letting calls pile up — thread exhaustion and latency amplification.
- Ignoring fallback design — saying the circuit breaker 'blocks calls' without explaining what the caller receives.
- Confusing circuit breaker with retry logic — retries amplify load on a struggling service; circuit breakers reduce it.
Follow-Up Questions
- How does a circuit breaker interact with a retry policy — should you retry before or after the circuit breaker checks? — Retry inside the circuit breaker — retries count as attempts; the breaker trips after N total failures across retries to prevent retry storms.
- What metrics would you monitor to tune circuit breaker thresholds in production? — Error rate, p99 latency, breaker state transitions per minute, fallback invocation rate — use these to tune threshold and timeout.
- How does Istio implement circuit breaking differently from application-level libraries like Resilience4j? — Istio applies circuit breaking at the sidecar proxy (Envoy) level based on connection count and consecutive errors — no application code changes needed but less granular control.
- What happens if the circuit breaker itself becomes a bottleneck — how is it implemented to avoid being in the critical path? — In-memory state per instance (no shared state), lock-free atomic counters, sliding window implemented as a ring buffer — must be nanosecond overhead.
Related Questions
Can You Explain This Cold?
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment