Circuit Breaker
maang.io System Design Series
A circuit breaker wraps calls to a dependency and, when failures cross a threshold, "trips" — failing fast instead of hammering a service that's already down. Like an electrical breaker, it moves through closed → open → half-open states, probing for recovery before letting traffic flow again. It's the pattern that stops one slow dependency from exhausting threads and cascading into a full outage.
This deep dive comes in three parts:
- Foundations & Core Concepts — the three states and the failure threshold.
- Internals — rolling-window failure counting, fallbacks, and related patterns (timeouts, bulkheads), with worked numbers.
- Interview — Staff/Principal Q&A: preventing cascades and library vs service-mesh placement.
Circuit Breaker — Part 3: System-Design Usage & Interview Mastery
maang.io System Design Series
What is this?
You've stood in front of the electrical panel twice now. In Part 1 you watched it trip and cautiously flip back on; in Part 2 you took the cover off and studied the bimetallic strip — the rolling window and the atomic state variable that decide, in a thread-safe instant, whether the next call flows or short-circuits. This chapter is where that knowledge earns you the offer.
An interviewer doesn't want you to recite "a circuit breaker has three states." They want to watch you reach for it at the right moment in a design, wire it into the rest of the resilience stack, and defend the trade-offs when they push back — "why not just retry?", "where does the breaker actually live?", "what if 80% of the fleet is down?". That's the difference between a memorized fact and a senior signal.
We'll do two things: first see where circuit breakers show up in real designs (with diagrams), then run a mock interview — for each question, what they're really asking, a model answer, and the senior line that signals you've operated this for real.
The one-line idea: interviewers use the circuit breaker to test whether you can reason about failure as a first-class part of the design — whether you know that in a distributed system a dependency will get slow, that a slow dependency is more dangerous than a dead one, and that the mature move is to stop calling it fast rather than politely wait it to death.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson