Problem
A failing dependency causes callers to hang, exhaust resources (threads, connections), and fail themselves — cascade.
resilienceestablished · low operational burden
Circuit Breaker
Also known as: circuit-breaker-pattern
Intent
Prevent cascading failures by stopping requests to a failing service, giving it time to recover.
Forces
- •Remote calls can fail or hang indefinitely
- •Callers have limited resources (thread pools, connection pools)
- •Failed service needs time to recover without load
- •Callers need fast failure to enable fallbacks
Solution
✓ When to Use
- •Any synchronous remote call (HTTP, gRPC, DB)
- •Downstream services with variable latency or reliability
- •When caller must remain responsive during downstream outage
✗ When Not to Use
- •Local in-process calls (no network failure mode)
- •Fire-and-forget async operations
- •When brief unavailability is worse than stale data (use cache instead)
Pros
- +Prevents cascade; protects caller resources
- +Automatic recovery via half-open
- +Enables fallback logic (cached data, degraded mode)
Cons
- −Adds latency (state check) to every call
- −Tuning thresholds is environment-specific
- −Doesn't help if failure is caller-side (bug, config)
Cost Profile
Infrastructure
None — library-level
Operational
Low — monitor open/closed transitions
Cognitive
Medium — understand state transitions
Failure Modes
Thundering herd on half-open if too many callers test simultaneously
Stuck open if timeout too short for actual recovery
Stuck closed if failure threshold never reached (e.g., slow failures)
Real-World Examples
Alternatives
- timeout-only
- bulkhead
- retry-with-backoff
Related Patterns
- timeout
- bulkhead
- retry-with-backoff
- fallback
Competency Domains
reliability opsdistribution communication