Record success and failure signals for the protected dependency.
Reliability & Delivery · Fault Handling
Circuit Breaker
Track failures and temporarily stop calls to an unhealthy dependency. Closed, open and half-open states let the system fail fast while still testing whether the dependency has recovered.
How can callers stop wasting time and capacity on a dependency that is likely to keep failing?GateSift summary based on Microsoft Azure Architecture Center guidance. The wording, visualization, Azure mapping and analyzer context are original GateSift material.
Original GateSift visualization
How Circuit Breaker works
Failure history determines whether a dependency call proceeds, fails immediately or probes for recovery.
Dependency call
Circuit state
Call allowed
Fail fast
Open the circuit when the failure threshold is exceeded and reject calls without waiting for timeouts.
Use a controlled half-open probe to close the circuit only after the dependency recovers.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use a circuit breaker when repeatedly calling an unhealthy dependency would waste resources, increase latency and make recovery harder.
- Dependency failures can persist long enough that normal retry becomes harmful.
- The caller has a meaningful fallback, degraded response or fail-fast behavior.
- Failure and recovery can be measured per dependency rather than across unrelated operations.
- Failures are extremely rare and short-lived, where bounded retry is sufficient.
- There is no sensible degraded behavior and callers must always wait for the dependency anyway.
- A global breaker would combine unrelated tenants or dependencies and cause unnecessary outages.
Bad thresholdsHigh impact
A breaker that opens too quickly creates outages; one that opens too slowly provides little protection.
Recovery stampedeReview
Too many probes or simultaneous retries after recovery can overload the dependency again.
Shared blast radiusHigh impact
One breaker state shared across unrelated operations can make a localized failure look global.
- Scope breaker state to the dependency and failure mode that actually share health characteristics.
- Pair fail-fast behavior with observable state transitions so operators can distinguish an open circuit from the dependency's original error.
- Use a controlled half-open probe strategy before returning full traffic to a recovered dependency.
What this pattern helps you decide
Track failures and temporarily stop calls to an unhealthy dependency. Closed, open and half-open states let the system fail fast while still testing whether the dependency has recovered.
What measurable failure threshold opens the circuit and for how long?
What does the caller do while the circuit is open?
How is recovery probed without sending the full workload immediately?
Where you may see it
- Application resilience libraries such as Polly
- API gateway or service-mesh dependency protection
- Fail-fast wrappers around remote service calls
How the analyzers can surface it
- Retry loops without a long-failure protection strategy
- Backend failover or health-probe behavior in APIM
- Repeated connector failures without a cooldown or alternate path
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
Source guidance and attribution
This page links to Microsoft Azure Architecture Center for the source architecture guidance. GateSift summaries, diagrams, Azure examples and analyzer signals are original. No endorsement by Microsoft is implied.