Circuit Breakers

The Problem: Calling Into a Fire

 dependency is failing at 80%. your calls:
 - wait for timeouts (latency explodes)
 - consume YOUR threads/connections
 - add 3% more load to its recovery problem

 every call into a dying service makes BOTH worse.

 CIRCUIT BREAKER (from electrical engineering):
 detect sustained failure → STOP CALLING → fail fast locally
 → probe occasionally → restore when healthy.

 [api] ──calls──►(breaker)──►[payments]
                    │
              OPEN? reject instantly with fallback

The Three States

 CLOSED (normal):
   calls flow; failures tracked over sliding window
   
   failure rate > threshold (e.g. 50% of ≥20 calls)?
        │
        ▼
 OPEN (tripped):
   ALL calls rejected IMMEDIATELY (no timeout wait!)
   callers get fast-fail → fallback paths engage
   after COOLDOWN (e.g. 30s) →
        │
        ▼
 HALF-OPEN (probing):
   small # of trial requests allowed through
   succeed? → CLOSED again ✓
   fail?    → back to OPEN, cooldown restarts

Why Fail-Fast Beats Fail-Slow

 comparison during dependency brownout:

 without breaker:
   latency: p99 = timeout value × queue effects (seconds)
   threads: exhausted → YOUR other endpoints die too
   user UX: spinners everywhere

 with breaker + fallback:
   latency: milliseconds (instant rejection)
   threads: free; system stays responsive
   user UX: degraded-but-working ("recommendations
            unavailable" vs whole page hanging)

 the breaker LOCALIZES failure instead of letting it spread.
 that's the entire point.

Tuning Without Whiplash

Parameter	Typical	Danger if wrong
failure threshold	50% of ≥20 calls	too low: trips on blips
sliding window	10–60s	too long: reacts slowly
cooldown	15–60s	too short: flapping; long: slow recovery
half-open probes	3–5 requests	too many: herd on sick service

 FLAPPING = open↔closed cycling (borderline health):
 fix with longer cooldowns + hysteresis (different
 trip/recover thresholds: trip at 50%, recover below 20%).

 per-DEPENDENCY breakers, never global — one sick
 dependency shouldn't break calls to healthy ones.

Breakers Need Fallbacks

 tripping without a plan = trading slow failure for errors:

 fallback ladder by endpoint type:
 - recommendations → return cached/popular defaults
 - reviews section → hide module ("unavailable")
 - auth → NO fallback. fail visibly (can't fake identity!)
 - payments → fail closed + queue for retry (never fake success)

 pair each breaker with an explicitly designed answer to
 "what do users see while it's open?" — decided BEFORE tripping,
 not improvised during the incident.

Interview Framing

“When recommendation service slows, your whole product page hangs” scored shape: circuit-breaker states drawn (closed→open→half-open), fail-fast-vs-thread-exhaustion contrast quantified, fallback-per-endpoint-type table, tuning-with-hysteresis mention, and the auth exception showing judgment. Breakers paired WITH their fallback plans is the complete answer; breakers alone are half a design.