Quick answer
The circuit breaker pattern prevents a backend service from repeatedly calling a dependency that is already failing. Instead of letting every request wait for a timeout, the circuit breaker detects repeated failures and temporarily stops calls to that dependency.
This protects the caller, gives the dependency time to recover, and reduces cascading failure across distributed systems.
Why circuit breakers matter
Backend services often depend on databases, payment providers, search systems, email providers, feature flag services, and internal APIs. When one dependency becomes slow or unavailable, callers can pile up waiting for timeouts.
That waiting is dangerous. Threads, connections, memory, and queues can fill up. A failure in one service can spread to services that were otherwise healthy.
A circuit breaker adds a controlled failure mode. When the dependency is unhealthy, the caller fails fast, returns a fallback, or skips non-critical work.
The three states
A circuit breaker usually has three states:
| State | Meaning |
|---|---|
| Closed | Calls are allowed. The dependency is considered healthy. |
| Open | Calls are blocked temporarily because failures crossed a threshold. |
| Half-open | A small number of test calls are allowed to see whether recovery has started. |
In the closed state, requests flow normally. If failure rate or timeout count exceeds the configured threshold, the breaker opens.
In the open state, the service stops calling the dependency for a cooldown period.
In the half-open state, the service allows limited probes. If they succeed, the breaker closes. If they fail, the breaker opens again.
A payment example
Imagine an order service that calls a payment provider.
Order API -> Payment providerIf the payment provider starts timing out, the order service should not keep hundreds of requests waiting for full timeout duration. A circuit breaker can open after repeated failures and return a clear temporary failure response.
For non-critical dependencies, the service may use a fallback. For example, analytics events can be skipped or queued later. Payment authorization usually cannot be skipped, so the response should clearly tell the client the operation cannot be completed right now.
Thresholds
Circuit breaker thresholds are usually based on:
- Consecutive failures.
- Failure percentage over a rolling window.
- Timeout count.
- Slow-call percentage.
- Minimum request volume before opening.
The minimum volume matters. If only one request fails, opening the breaker for the whole service may be too aggressive. A rolling window prevents one tiny sample from making a large decision.
Fallbacks
A fallback is an alternate response when the dependency is unavailable.
Good fallbacks are domain-specific:
| Dependency | Possible fallback |
|---|---|
| Recommendations | Return popular items. |
| Feature flags | Use cached defaults. |
| Analytics | Drop or enqueue the event. |
| Profile service | Return partial page without profile details. |
| Payment provider | Return a retryable checkout error. |
Do not hide critical failures. A fallback should not pretend a payment succeeded or that a write was durable when it was not.
Circuit breakers and retries
Retries and circuit breakers should work together carefully.
Retries can help when failures are brief and transient. But aggressive retries can make an outage worse by multiplying traffic. A circuit breaker stops retry storms by failing fast after the dependency is clearly unhealthy.
Read Retry Patterns Explained after this guide for backoff, jitter, retry budgets, and safe retry behavior.
Common mistakes
The first mistake is setting thresholds without real latency and error data. A breaker that opens too easily can create false outages. A breaker that opens too late may not protect anything.
The second mistake is using the same breaker for unrelated calls. A search endpoint and a payment endpoint should usually have separate breakers because their dependencies, risks, and fallbacks differ.
The third mistake is not monitoring breaker state. If a breaker is open, that is operationally important. Metrics should show open duration, open count, failure rate, and fallback usage.
The fourth mistake is using a fallback that violates business correctness.
Backend checklist
When adding a circuit breaker:
- Define the dependency and operation being protected.
- Set timeout values before breaker thresholds.
- Choose failure-rate or slow-call thresholds.
- Configure open-state duration.
- Decide whether a fallback is safe.
- Add metrics for breaker state and fallback usage.
- Test closed, open, and half-open behavior.
Related reading
Read Rate Limiting in APIs Explained for traffic protection at the API boundary and Message Queues Explained for moving slow work out of request paths. For duplicate-safe retry behavior, read Idempotency in APIs Explained. You can also browse the System Design topic cluster for related resilience guides.