Circuit Breaker Pattern
The Circuit Breaker pattern stops calls to a failing dependency once errors exceed a threshold, returning fast fallbacks instead of hanging. It prevents one bad dependency from cascading into a full outage and gives it room to recover.
Best Practice: Circuit Breaker Pattern
The Circuit Breaker protects a system from a failing dependency the way an electrical breaker protects a house. When calls to a remote service start failing past a threshold, the breaker trips and short-circuits further calls, returning an error or fallback immediately instead of waiting on timeouts. After a cooldown it allows a trial call; if that succeeds, it closes again. This prevents one slow or down dependency from exhausting threads and cascading into a full outage. Michael Nygard introduced the pattern in Release It! and Martin Fowler documented it widely. It matters in any distributed system where a remote call can fail or hang.
Step-by-Step Implementation Guidance
- Identify remote calls that can fail or become slow.
- Define the breaker states: closed (normal), open (short-circuiting), and half-open (trial).
- Set a failure threshold and time window that trips the breaker to open.
- Set a cooldown after which the breaker moves to half-open for a trial call.
- Provide a fallback: cached data, a default value, or a graceful error.
- Combine with sensible timeouts and bounded retries so failures surface quickly.
- Emit metrics on breaker state transitions for alerting and tuning.
Common Mistakes Teams Make When Ignoring This Practice
- Letting a slow dependency hang threads until the whole service falls over.
- Retrying aggressively against a downed service and amplifying the outage.
- Setting thresholds without data, so the breaker trips too early or never.
- Providing no fallback, so a tripped breaker just propagates errors.
- Not monitoring breaker state, so operators miss a degraded dependency.
Tools and Techniques That Support This Practice
- Resilience4j for Java applications.
- Polly for .NET applications.
- Service meshes such as Istio that apply breakers at the network layer.
- Envoy proxy outlier detection.
How This Practice Applies to Different Migration Types
- Cloud Migration: Protect calls that cross the on-premise-to-cloud boundary during a phased cutover.
- Database Migration: Break the circuit on a struggling new datastore and fall back while it stabilizes.
- SaaS Migration: Shield your app when an external SaaS API degrades.
- Codebase Migration: Wrap newly extracted services so early instability does not topple the caller.
Checklist
- Identify all remote calls that can fail or hang.
- Configure failure thresholds and time windows.
- Implement closed, open, and half-open states.
- Define fallbacks for the open state.
- Pair breakers with timeouts and bounded retries.
- Emit metrics on state transitions.
- Load-test failure scenarios to tune thresholds.