# Circuit Breaker Pattern: The Interview Answer That Shows You Build Resilient Systems
Circuit Breaker Pattern: The Interview Answer That Shows You Build Resilient Systems
Circuit Breaker is a resilience pattern that prevents repeated calls to a failing dependency so your system can stay responsive and avoid cascading failures. In interviews, explaining this pattern well shows you think about availability, fault isolation, and observability — all key for building resilient systems.
## The three states (and what they mean)
- Closed
- Normal operation: traffic flows to the dependency.
- Failures are tracked (counts, rates, windows).
- When failures cross configured thresholds, the breaker trips to Open.
- Open
- Fail-fast mode: calls to the failing dependency are rejected immediately (or handled by a fallback).
- Prevents resource exhaustion and reduces load on the broken service.
- After a configured delay, the breaker transitions to Half-Open to test recovery.
- Half-Open
- A few probe requests are allowed through to verify the dependency’s health.
- If probes succeed (within thresholds), the breaker closes and normal traffic resumes.
- If probes fail, the breaker re-opens and the cycle repeats.
## Why interviewers care
- Prevents cascading failures across services.
- Improves system recovery and reduces mean time to recovery (MTTR).
- Provides predictable behavior under partial outages (fail-fast + fallbacks).
- Shows you design with fault isolation, graceful degradation, and observability in mind.
## Practical tuning guidance (what to mention in an interview)
- Thresholds
- Consecutive failures: trip after N failures in a row (N = 3–10 is common).
- Failure rate: trip if error rate > X% over a time window (e.g., 50% over 10s).
- Timeouts
- Set a sensible request timeout before counting a failure (prevents slow calls from piling up).
- Sleep window (open duration)
- How long the circuit stays Open before allowing probes (e.g., 10–60s). Shorter windows allow faster recovery but may cause flapping.
- Half-Open probes
- Limit concurrent probes (e.g., 1–5). Gradually increase on success.
- Backoff strategies
- Exponential backoff for retrying the dependency or enlarging the sleep window on repeated failures.
Example sensible defaults (starting point, not universal):
- Timeout: 2s
- Trip: 5 consecutive failures or 50% failure rate over 10s
- Sleep window: 30s
- Half-Open probe limit: 2
## Monitoring & alerting
Instrument and alert on:
- Circuit state transitions (Open/Half-Open/Closed)
- Failure rate and success rate
- Latency percentiles for the dependency
- Number of requests short-circuited (rejected by the breaker)
Dashboards and alerts let you spot noisy neighbors, flapping circuits, or configuration issues quickly.
## Interactions with other patterns
- Retries: Use carefully — retries + long timeouts can worsen cascading failures. Prefer fail-fast then fallback.
- Bulkhead: Isolate resource pools so one failing dependency doesn’t consume all threads/connections.
- Fallbacks: Return cached responses, default values, or degraded features while dependency is down.
## Common pitfalls
- Too aggressive thresholds that open the circuit for brief spikes.
- Not instrumenting state transitions — you won’t know when breakers trip.
- Using retries without timeouts or without considering the circuit state.
- Applying one global circuit for multiple endpoints that have different failure characteristics.
## How to explain it in an interview (concise script)
1. State the problem: "We want to stop repeated calls to an unhealthy dependency to avoid cascading failures."
2. Describe the pattern: "A Circuit Breaker tracks failures and cycles through Closed, Open, and Half-Open states to isolate faults."
3. Mention tuning & monitoring: "I’d tune thresholds, timeouts, probe behavior, and instrument state transitions and error/latency metrics."
4. Give trade-offs and related patterns: "Be careful with retries and add bulkheads/fallbacks for graceful degradation."
5. Optional: provide a brief config example (values and why).
## Minimal pseudocode (state machine)
```
if circuit == OPEN:
return fallback()
response = callRemoteWithTimeout()
if response.success:
resetFailureCount()
if circuit == HALF_OPEN: closeCircuit()
return response
else:
incrementFailureCount()
if failureCount > threshold: openCircuit()
return fallback()
// timer: after sleepWindow -> set circuit = HALF_OPEN
```
## Takeaway
When you describe the Circuit Breaker in an interview, cover the problem it solves, the three states, how you’d tune thresholds/timeouts, how you’d monitor it, and how it composes with retries, bulkheads, and fallbacks. That shows you design for resilience, not just functionality.
#SystemDesign #CircuitBreaker #DistributedSystems #Microservices #ReliabilityEngineering #SRE #BackendEngineering #SoftwareEngineering #InterviewPrep