Circuit Breaker

Start from brute force

The obvious first version has two states. Count consecutive failures, open at threshold, reject until opened_at + cooldown, then flip straight back to closed with the count at 0. It costs O(1) time per call and O(1) space, and it even passes the first example. It is wrong when the dependency is still down after the cooldown: every caller rushes back in, and the breaker needs threshold fresh failures before it trips again. With threshold = 2, cooldown = 10 and failures at t = 0, 1, 11 and 12, it returns four "fail"s, while the spec sends one probe at t = 11 and rejects t = 12.

The approach

Keep exactly the reference’s three variables: state ("closed" or "open"), fails (consecutive failures while closed) and opened_at. Half-open is not stored. It is the moment an open breaker’s cooldown has expired, which the reference detects as probing = state == "open" once the rejection check has passed.

Every call takes one of three paths. Open with t < opened_at + cooldown: append "rejected" and change nothing. A success, whether closed or probing: append "ok", set fails = 0 and state = "closed". A failure: when probing, only move opened_at to t, which starts a full new cooldown; when closed, increment fails and open at t once it reaches threshold. The invariant: the dependency is called only while closed, or for exactly one probe per expired cooldown.

Walk through an example

On the first example (threshold = 2, cooldown = 10) the breaker trips at t = 1, rejects one call, and is healed by the probe at t = 11.

Complexity

The replay is O(n) time for n calls, O(1) per call (one comparison and a few assignments), and O(1) extra space beyond the output list. The two-state version has the same cost; its problem is correctness, not speed. A live breaker shared across threads is still O(1) per call, but its state must be updated atomically.

Edge cases to test

• A call exactly at opened_at + cooldown is the probe, and one just before it is not: circuit_breaker(1, 10, [[0, False], [9.999, True], [10, True]]) returns ["fail", "rejected", "ok"], because the check is a strict t < opened_at + cooldown.
• A failed probe restarts the cooldown from the probe’s own time: circuit_breaker(1, 10, [[0, False], [10, False], [15, True], [20, True]]) returns ["fail", "fail", "rejected", "ok"]; t = 15 is rejected because the window now ends at 20.
• Failures split by a success never trip: circuit_breaker(2, 10, [[0, False], [1, True], [2, False], [3, True]]) returns ["fail", "ok", "fail", "ok"].
• Rejections change nothing: with threshold = 1, cooldown = 100, calls at t = 50 and t = 99 that would succeed are both "rejected", and neither touches fails or opened_at.
• A cooldown of 0 makes the very next call the probe: circuit_breaker(1, 0, [[0, False], [0, True], [0, True]]) returns ["fail", "ok", "ok"]. An empty calls list returns [].

Common mistakes

• Not resetting the failure count on success, so the breaker trips on unrelated intermittent errors.
• Skipping the half-open trial — the breaker then either sticks open forever or flaps between states.
• Incrementing fails on a failed probe but leaving opened_at at the original trip: the cooldown has already expired, so the very next call is probed again instead of waiting a full cooldown.
• Using <= in the cooldown check, which rejects the call landing exactly on opened_at + cooldown instead of probing it.

Follow-ups an interviewer asks next

Which errors should count as failures?

Only the ones that say the dependency is unhealthy: timeouts, connection errors and 5xx responses. A 4xx such as 404 or 422 means this request was wrong, not that the service is down, and counting it lets one buggy caller trip the breaker for everyone. A 429 is a health signal too, but it usually calls for backing off, which a retry policy handles.

How would you trip on a failure rate instead of a consecutive count?

Keep a sliding window of the last N calls, or of the last T seconds, and trip when the failure ratio crosses a threshold, but only once the window holds a minimum number of calls, so two failures out of two calls do not read as 100%. resilience4j configures its breakers this way: a window type and size, a failure-rate threshold and a minimum number of calls.

What should half-open do when many requests arrive at once?

Admit a fixed number of trial calls and reject the rest until those finish, so a recovering dependency is not hit with the full load at once. In a concurrent service that takes an atomic compare-and-set on the state; otherwise every thread that sees the expired cooldown sends its own probe. Some designs also require several successful probes before closing.

The service runs on 50 instances. Shared breaker or one per instance?

Usually one per instance. The state is tiny, decisions stay local and fast, and a dependency failing for one instance (a bad network path) may be fine for the others. A shared breaker in Redis gives fleet-wide agreement, but it adds a network hop to every call and a new dependency that can fail on its own.

Where this shows up

The circuit breaker stops a failing dependency from taking your service down with it: fail fast so threads are not parked on timeouts, and give the sick dependency room to recover. It is a staple of resilient microservices (Hystrix, resilience4j), used alongside retries-with-backoff and bulkheads.

Reference solution

def circuit_breaker(threshold, cooldown, calls):
    out = []
    state = 'closed'
    fails = 0
    opened_at = 0.0
    for t, ok in calls:
        if state == 'open' and t < opened_at + cooldown:
            out.append('rejected')
            continue
        # closed, or the half-open probe
        probing = state == 'open'
        if ok:
            out.append('ok')
            fails = 0
            state = 'closed'
        else:
            out.append('fail')
            if probing:
                opened_at = t
            else:
                fails += 1
                if fails >= threshold:
                    state = 'open'
                    opened_at = t
    return out


print(circuit_breaker(2, 10, [[0, False], [1, False], [2, True], [11, True], [12, True]]))

type Outcome = 'ok' | 'fail' | 'rejected';

function circuitBreaker(threshold: number, cooldown: number, calls: [number, boolean][]): Outcome[] {
  const out: Outcome[] = [];
  let state: 'closed' | 'open' = 'closed';
  let fails = 0;
  let openedAt = 0;
  for (const [t, ok] of calls) {
    if (state === 'open' && t < openedAt + cooldown) {
      out.push('rejected');
      continue;
    }
    const probing = state === 'open';
    if (ok) {
      out.push('ok');
      fails = 0;
      state = 'closed';
    } else {
      out.push('fail');
      if (probing) {
        openedAt = t;
      } else {
        fails += 1;
        if (fails >= threshold) {
          state = 'open';
          openedAt = t;
        }
      }
    }
  }
  return out;
}

console.log(circuitBreaker(2, 10, [[0, false], [1, false], [2, true], [11, true], [12, true]]));