Circuit Breakers
Stop repeated calls to an unhealthy dependency and probe recovery deliberately.
2–5 minute refresher
Timeout→Backoff→Jitter→Retry budget→Circuit breaker→Load shedding
Closed → failure threshold → open → limited probes → closed
30second
refresher
refresher
A circuit breaker observes dependency outcomes and temporarily rejects calls when failure indicates continued attempts are harmful. After a pause it admits limited probes before restoring traffic.
What problem does it solve?
Repeated slow or failing calls consume threads, connections, and retry capacity, spreading one dependency failure into caller saturation.
How it works
- Record meaningful failures and slow outcomes over a bounded window.
- Open when volume and failure thresholds indicate harm.
- Return a fast fallback or explicit unavailable result.
- After a cooldown, allow a small number of half-open probes.
- Close gradually on recovery or reopen immediately when probes fail.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Sensitive threshold | Fast protection | False trips |
| Long cooldown | Recovery breathing room | Delayed restoration |
| Fallback | Preserve user journey | Staleness or reduced functionality |
What happens if?
Every application instance probes at once
Synchronized half-open probes can overload a recovering dependency. Add jitter, cap probe concurrency, and coordinate at an appropriate scope.
Where it appears
- Resilience4j
- Envoy outlier detection
- Service clients
- API gateways
Senior interview modeHow is a circuit breaker different from a retry policy?Show answer
Retries attempt recovery for an individual operation; a breaker uses recent system evidence to stop new attempts temporarily and protect shared resources. They must share one budget.