Circuit Breaker Pattern

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

1. Identify remote calls that can fail or become slow.
2. Define the breaker states: closed (normal), open (short-circuiting), and half-open (trial).
3. Set a failure threshold and time window that trips the breaker to open.
4. Set a cooldown after which the breaker moves to half-open for a trial call.
5. Provide a fallback: cached data, a default value, or a graceful error.
6. Combine with sensible timeouts and bounded retries so failures surface quickly.
7. 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.