circuit-breaker

Create a CircuitBreaker class tracking state (closed, open, half-open), failure counts, and timestamps. Wrap service calls in its call method, which raises an exception when open and transitions to half-open after the configured timeout expires.

Use 5-10 consecutive failures or a 50% failure rate across the last 10 requests. Rate-based breakers need a minimum request count (around 5) before evaluating the threshold to avoid opening on sparse traffic.

Combine them by layering retries inside the breaker, such as tenacity's stop_after_attempt with exponential backoff. Retries handle transient errors while the breaker opens when failures persist beyond the threshold.

Yes, use a distributed circuit breaker backed by Redis to share the open/closed state across servers. Each instance keeps a local breaker but publishes state changes to a shared Redis key with an expiration.

Common fallbacks include cached responses from Redis, safe default values, or degraded functionality like simple SQL search replacing ML-ranked results. User-facing features should always have a fallback defined.

The half-open state requires all test requests (typically 3) to succeed before closing. If any test fails, the circuit reopens, so verify the downstream service has actually recovered and the timeout duration is sufficient.