Day 14 of building OrderHub in the open. So far we have a monolith with real persistence, validation, exception handling, OpenAPI docs, a Redis cache, and a rate limiter. Today we add the piece that keeps the whole thing standing when a dependency falls over instead of a client: a circuit breaker.
Here's the scenario. Placing an order needs a stock check, so the order flow calls an inventory service. That service gets slow, or starts throwing 5xxs. The naive reaction is the dangerous one: keep calling it, keep retrying. Threads pile up blocked on a dead dependency, timeouts stack, connection pools drain, and within seconds a problem in inventory has become an outage in OrderHub. That cascade is how small failures become big ones.
A circuit breaker is a fuse for service calls. It watches how recent calls have gone, and when too many fail it stops calling the dependency for a while — returning a fast fallback instead. The struggling service gets room to recover, and your service stays responsive. Isolation instead of propagation.
The three states
The breaker is a small state machine with three states.
