Course contentsShow
← Databases & SQL
Lesson 1304 of 1,95312. Key-Value and Caching EnginesFree lesson

Implementing Circuit Breakers

Use the cache to track failure states of downstream services to prevent cascading failures.

In this lesson, you will learn how to use a caching engine to act as a "circuit breaker" that stops your application from slamming a failing downstream service with requests it cannot handle.

The Concept of the Circuit Breaker

When a downstream service (like a slow microservice or an overloaded database) starts failing, continuing to send requests only makes the situation worse—this leads to cascading failures that can eventually crash your entire system. A circuit breaker pattern uses a shared cache to track the "health" of that service. If the error rate crosses a threshold, the "circuit" trips, and your application stops trying to reach the service, instantly returning a failure or a cached fallback instead.

Using Redis to Track State

We can track the state of a service in Redis using a simple string key. The state typically moves between three modes: CLOSED (service is fine), OPEN (service is failing, stop sending requests), and HALF-OPEN (test the service with a small probe).

Consider this simplified logic for a service check:

# Check if the circuit is open
state = redis.get("circuit:orders-service:state")

if state == "OPEN":
    return get_fallback_data() # Stop calling the service entirely

try:
    result = call_downstream_service()
    reset_failure_count()
    return result
except ServiceException:
    # Increment failure count in Redis
    count = redis.incr("circuit:orders-service:failures")
    if count >= THRESHOLD:
        # Trip the circuit for 60 seconds
        redis.setex("circuit:orders-service:state", 60, "OPEN")
    return get_fallback_data()

Why use a cache for this?

Because circuit breaker state must be global. If you have ten instances of your application server, they all need to know immediately that the downstream service has failed. By storing the state in your Redis cache rather than local server memory, your entire fleet of services acts as one synchronized unit. If the circuit trips on one server, the other nine will see the OPEN state in the cache and stop hitting the struggling service as well, giving it the necessary "breathing room" to recover.

Key Takeaway: Use a shared cache to monitor service health and trip a circuit breaker to prevent cascading failures by failing fast instead of overwhelming a struggling downstream system.