The breaker wraps calls to one dependency and counts failures; past a threshold it opens and fails calls at once for a cool-down period, then half-opens to let a few trial calls through, closing if they succeed and reopening if they fail. Callers stop spending threads and timeouts on a dependency that is down, and the dependency gets room to recover (Martin Fowler, CircuitBreaker; Azure Architecture Center, Circuit Breaker pattern).
Forerunner Industries’ public fde-take-home repository (created in May 2025; its README gives no task text) holds a mock permit-system API built “with intentional issues to test integration resilience”: it rate-limits after 5 consecutive requests within 10 seconds and gives any request a 20% chance of an HTTP 500 error. Source 1Permit System APIPublisherForerunner Industries (GitHub organization)Source typecompany website That mock is mostly not a breaker case. Random, independent failures call for retries with , and a rate limit calls for a client-side limiter and honoring Retry-After when the server sends it; a breaker that trips on them refuses calls that would have succeeded.
Count only failures that say the dependency is unhealthy (timeouts, connection errors, HTTP 5xx), never HTTP 400 or HTTP 429. Trip on consecutive failures or on a sustained failure rate over a minimum request volume, so one bad call in a quiet minute does not open it. Keep one breaker per dependency (and per tenant, where one customer’s failures should not trip another’s), and remember that each instance of your service holds its own breaker state. Say what the caller does while it is open: serve cached data, queue the work, fail over to a second provider, or fail fast with a clear error. Backoff rides out a brief blip; the breaker stops those retries from hammering a dependency that is down. Build one against a fake clock in the circuit breaker question.