Backend & Node.js · APIs, data and failure
What is a circuit breaker and when should you use one?
Short answer
A circuit breaker stops calling a failing dependency after a threshold, failing fast instead of piling up timeouts. It moves through closed, open and half-open states, and probes recovery with limited traffic.
Timeouts and retries help a single request, but when a dependency is down, every request still waits and consumes a connection or thread. A circuit breaker tracks failures and opens the circuit, so callers get an immediate error or fallback while the dependency recovers.
if (breaker.state === "open") {
if (Date.now() < breaker.openedUntil) {
throw new CircuitOpenError("dependency unavailable");
}
breaker.state = "half-open";
}
const result = await callDependency();
breaker.recordSuccess();Design details
- Count failures over a window, not a single error
- Use a cooldown before the half-open probe
- Allow only a small number of probe requests while half-open
- Scope the breaker per dependency and tenant where needed
- Provide a fallback, cached response or degraded mode
- Emit metrics for state changes and rejected calls
A breaker is not a substitute for a timeout. Every call still needs a deadline, because a slow dependency can hold resources even if it eventually succeeds. Combine the breaker with retries carefully: retries inside an open circuit just multiply failures.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What are the three circuit breaker states?
- 2How does a half-open probe work?
- 3Why is a timeout still necessary?
- 4Which errors should count toward opening the circuit?
Say it in the interview
A circuit breaker monitors failures to a dependency and opens after a threshold, so callers fail fast instead of waiting on timeouts. After a cooldown it goes half-open and lets a few probes through; success closes it, failure reopens it. I still set timeouts on every call and provide a fallback or degraded response. Client errors such as 400 should not trip the breaker because they are not dependency failures.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Backend & Node.js mock interview and get scored feedback on depth, clarity and confidence.