Railway Security Disclosure: Wednesday October 21st
Concept of the day · architecture
Circuit Breaker
Stop calling a dependency that is already failing, so you fail fast instead of piling up.
The mechanism. A breaker wraps a remote call and tracks its failure rate. In closed state, calls pass through. When failures cross a threshold, it trips to open and fails immediately without calling — no socket, no timeout wait. After a cooldown it moves to half-open and lets a few probes through; success closes it, failure re-opens it.
The problem it actually solves. It is not about the failing dependency; it is about you. Without a breaker, every request to the sick service occupies a thread or a connection for the full timeout. Those resources are shared, so your healthy endpoints starve and a single slow dependency takes the whole service down. That is the cascading failure.
Getting it wrong. Too sensitive and you trip on normal jitter, turning a 1% error rate into a 100% outage. Thresholds should be a rate over a window with a minimum request count, never a raw count. And the breaker needs a fallback: a cached value, a degraded response, a queued retry. A breaker without a fallback just converts slow failures into fast ones, which is an improvement but not a feature.
Related tools. Bulkheads (separate pools per dependency, so one cannot starve the others) and timeouts (a breaker cannot help if your timeout is 60 seconds, because you will exhaust the pool long before the threshold trips). Timeouts first, then bulkheads, then breakers.
Takeaway. Set the timeout, isolate the pool, then add the breaker. In that order.