# Circuit breakers > A circuit breaker temporarily stops calls to a dependency that appears unhealthy, so repeated failures do not consume more resources or worsen an outage. In system design interviews, use it to explain how a slow payment provider, notification service, or internal API can fail without exhausting the services that call it. Source: https://sysround.com/concepts/circuit-breaker Updated: 2026-11-05 ## How circuit breakers works Place a breaker around calls to a particular dependency or operation, usually in the calling service's client library or proxy. It tracks outcomes such as connection failures, timeouts, and selected server errors; ordinary validation failures usually should not count. In the closed state, calls pass through normally. The breaker opens when a configured rule is met, such as at least 50% failures in a rolling 10-second window with a minimum of 20 completed calls. The minimum sample size prevents a single failure at low traffic from opening the circuit. In the open state, new calls fail immediately without contacting the dependency. The caller can return an explicit unavailable response, serve acceptable cached data, or defer durable work; it must not report an operation as successful when it was never completed. After a cooldown, the breaker enters the half-open state and permits a small number of recovery probes. Successful probes close it; failed probes reopen it. Limit probe concurrency and stagger recovery across callers so they do not all resume traffic at once. Scope breakers to meaningful failure boundaries. For example, an unhealthy SMS provider should not stop email delivery, and a failing endpoint should not necessarily disable every operation on the same service. Breaker state is often local to each caller instance, so instances can reach different conclusions. Combine the breaker with request deadlines, bounded concurrency, and controlled retries. Opening a circuit does not automatically cancel existing calls or resolve their outcomes, and callers should not immediately retry requests rejected by an open breaker. ## Worked example: Isolating a failing SMS provider Suppose a notification service has 10 worker instances, each sending 100 SMS requests per second. Each instance uses a provider-specific breaker with a 10-second rolling window, a minimum of 20 completed calls, and a 50% failure threshold. Calls have a 1-second deadline. When the provider starts timing out, breakers open as their thresholds are reached. Workers defer unsent messages in durable storage with delayed retries instead of repeatedly calling the provider; email workers continue independently. After a jittered cooldown of about 30 seconds, each instance permits one probe at a time, so fleet-wide probes can still reach 10 concurrent calls. Recovery resumes gradually. Timed-out sends remain uncertain and require provider-supported idempotency or delivery-status reconciliation. ## Trade-offs - **Containment versus rejected work.** Failing fast preserves caller resources but can reject calls that the dependency might have served successfully. - **Detection speed versus false trips.** Small windows and low thresholds react quickly but can mistake brief errors or sparse traffic for an outage. - **Recovery speed versus renewed overload.** Conservative probes delay restoration, while aggressive probes or an immediate return to full traffic can overwhelm a recovering dependency. - **Isolation versus configuration complexity.** Fine-grained breakers contain failures more precisely but create more state, thresholds, and metrics to manage. - **Local simplicity versus fleet-wide behavior.** Local breakers avoid a shared coordination dependency, but total probe traffic grows with the number of caller instances. - **Fallback availability versus correctness.** Cached or deferred results can preserve useful service only when their staleness and delivery semantics meet the operation's requirements. ## When to use it in a system design interview - A synchronous request depends on an external provider whose latency and availability you cannot control. - One failing downstream service could exhaust caller threads, connections, or other shared resources. - Retries are increasing traffic to an already unhealthy dependency. - The design has a clear failure policy: serve stale data, defer durable work, disable an optional feature, or return unavailable. - Independent providers or operations need separate failure containment. ## How to bring it up in the interview - Start with the failure chain: a slow dependency holds connections, caller capacity fills, and unrelated requests begin failing. Explain which calls the breaker stops. - Specify the counted failures, observation window, minimum sample size, cooldown, and half-open probe limit; present initial values as tuning choices, not universal defaults. - State the user-visible behavior while open. Interviewers will probe whether a fallback hides stale data, loses queued work, or falsely reports payment success. - Distinguish the supporting controls: deadlines bound individual waits, bulkheads bound shared resource use, and retry budgets bound extra attempts. - Explain how you would validate it: track state transitions, rejected calls, downstream latency, fallback usage, and probe outcomes, then test outages and recovery across many caller instances. ## Common mistakes - Treating a circuit breaker as a timeout replacement; early calls can still hang unless they have deadlines. - Counting every client error as dependency failure, allowing invalid requests to trip the circuit. - Putting all dependencies behind one breaker, so an isolated failure disables healthy paths. - Retrying open-circuit rejections in a tight loop or allowing every instance to send unlimited recovery probes. - Assuming a timeout means no side effect occurred, then retrying payments or switching providers without idempotency and outcome reconciliation. ## Interview questions where it comes up - [Design a notification system](https://sysround.com/questions/design-notification-system): Provider-specific breakers keep slow delivery channels from consuming worker capacity while durable retries preserve pending notifications. - [Design a payment system](https://sysround.com/questions/design-payment-system): Breakers contain external processor outages, but rejected calls and ambiguous in-flight charges need distinct handling to avoid duplicate money movement. - [Design a weather app](https://sysround.com/questions/design-weather-app): Breakers stop repeated calls to failing weather sources while the service serves cached observations with explicit freshness information. - [Design an on-call escalation system like PagerDuty](https://sysround.com/questions/design-pagerduty): Provider breakers contain delivery outages while durable escalation continues without treating a skipped or uncertain send as confirmed delivery. ## FAQ ### What are the three states of a circuit breaker? Closed allows normal calls while recording outcomes. Open rejects new calls without contacting the dependency. Half-open allows limited probes to decide whether normal traffic can resume. ### What is the difference between a circuit breaker and retries? Retries make additional attempts when a failure may be temporary; a circuit breaker stops attempts when recent outcomes suggest the dependency is unhealthy. They can work together, but retries need backoff, jitter, and a budget, and should stop when the breaker rejects a call. ### How is a circuit breaker different from a rate limiter? A rate limiter enforces a configured traffic allowance, usually regardless of whether the destination is healthy. A circuit breaker changes admission based on observed failures or slow calls. Rate limits can protect normal capacity while breakers contain failure-driven overload. ## Related concepts - [Retries, backoff and jitter](https://sysround.com/concepts/retries-backoff) - [Bulkheads](https://sysround.com/concepts/bulkheads) - [Load shedding](https://sysround.com/concepts/load-shedding) - [Observability](https://sysround.com/concepts/observability) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.