Circuit Breaker — Part 2: Internals & Implementation

maang.io System Design Series

What is this?

Back to the electrical panel. In Part 1 we watched it trip and cautiously flip back on. But a real breaker in your wall isn't magic — inside is a bimetallic strip that bends as it heats up under current, and a spring-loaded latch that releases when the strip bends far enough. The physics of the strip is what turns "too much current for too long" into a mechanical trip. Get the strip's sensitivity wrong and the breaker either trips on every toaster (too twitchy) or lets the wires cook before it acts (too sluggish).

A software circuit breaker has the same hidden machinery. The three states from Part 1 are the easy part; the engineering is in the counter that decides when to trip — the equivalent of that bimetallic strip. How exactly do you measure "too many failures"? Over what window? How do you do it correctly when thousands of threads are hammering the same breaker at once? And how do you probe for recovery without accidentally sending a herd of requests at a service that's barely back on its feet? That's this chapter.

The one-line idea: The whole breaker hangs off one data structure — a rolling window of recent call outcomes — plus an atomically-guarded state variable. The window turns a stream of successes and failures into a live error-rate; the state variable decides, in a thread-safe instant, whether the next call flows or short-circuits. Master those two and you understand every circuit breaker ever written.