Implement a Circuit Breaker for Flaky API Calls

Q: Implement a Circuit Breaker for Flaky API Calls

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Hard > **How to read this doc:** the full real state cycle — CLOSED, tripping OPEN after enough failures, a call while OPEN being rejected WITHOUT even invoking the real underlying function, and eventual recovery through HALF_OPEN back to CLOSED — was verified directly against a real, genuinely flaky function. ## 1. The problem, restated Repeatedly calling a real, currently-failing downstream service wastes real time and resources on calls almost certain to fail anyway. A circuit breaker tracks REAL failures and, once enough accumulate, "trips open" — REJECTING further calls IMMEDIATELY, without even attempting the real underlying call — for a cooldown period, after which it cautiously allows exactly one real test call through to check if the real service has recovered. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | The real 3 sta

The problem

Problem, as an interviewer would state it: "Implement a circuit breaker wrapping a flaky async function — after enough real failures, STOP calling the real function entirely for a cooldown period, then cautiously try again."

Examples:

Code

const breaker = createCircuitBreaker(flakyApi, { failureThreshold: 3 });
// after 3 real failures, breaker.call() rejects IMMEDIATELY, without even invoking flakyApi

Clarifying questions expected:

What are the real, standard circuit-breaker states, and what triggers each transition between them?
After the cooldown period, does the breaker immediately go back to normal, or cautiously test ONE real call first?
Should a successful call during the cautious "testing" phase fully reset the breaker back to normal?

Code / implementation expected: Yes — real, direct proof of a FULL real state cycle: real failures tripping it open, an immediately-rejected call while open (with a real call counter confirming the function was genuinely never invoked), and real recovery after the cooldown.

resilience
async
system-design

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Hard

How to read this doc: the full real state cycle — CLOSED, tripping OPEN after enough failures, a call while OPEN being rejected WITHOUT even invoking the real underlying function, and eventual recovery through HALF_OPEN back to CLOSED — was verified directly against a real, genuinely flaky function.

1. The problem, restated

Repeatedly calling a real, currently-failing downstream service wastes real time and resources on calls almost certain to fail anyway. A circuit breaker tracks REAL failures and, once enough accumulate, "trips open" — REJECTING further calls IMMEDIATELY, without even attempting the real underlying call — for a cooldown period, after which it cautiously allows exactly one real test call through to check if the real service has recovered.

2. Clarifyi

The solution is hidden so you can try first

7 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: a full circuit-breaker cycle against a genuinely flaky function — tripping OPEN, rejecting without invoking the function, and recovering