Circuit Breaker Pattern in Microservices

Hello Techies,

In the series of microservices design patterns, today I am sharing Circuit Breaker Design Pattern in microservices. In my previous blog post, I discussed in detail about Service Registry Pattern.

What is a circuit breaker?

The Circuit Breaker pattern is a design pattern used in distributed systems to handle failures and prevent cascading failures. It acts as a safety mechanism between a client and a remote service or resource. When failures occur, the circuit breaker “trips” and prevents further calls to the failing service, instead returning a predefined fallback response. This pattern helps to improve system resilience, prevent resource exhaustion, and reduce the impact of failures.

States in the Circuit Breaker pattern

The Circuit Breaker Design Pattern has three main states that represent its behavior and responsiveness to failures: ‘CLOSED‘, ‘OPEN‘, and ‘HALF_OPEN‘. These states determine how the circuit breaker handles requests to a potentially failing operation. Let’s look at each state in detail:

CLOSED State:

• In the ‘CLOSED‘ state, the circuit breaker allows the normal flow of requests to the operation or service.
• The circuit is considered “closed” because it lets requests pass through, assuming the operation is functioning correctly.
• When a request is made to the operation, it executes as usual.
• If the operation succeeds, the circuit breaker remains in the 'CLOSED‘ state.
• If the operation fails (e.g., due to a timeout or an exception), the circuit breaker increments the failure count.
• If the number of consecutive failures reaches a pre-defined threshold, the circuit breaker moves to the ‘OPEN‘ state.

OPEN State:

• In the ‘OPEN‘ state, the circuit breaker prevents requests from reaching the operation, effectively “opening” the circuit to stop any further calls.
• Instead of forwarding the requests, the circuit breaker returns a predefined fallback response to the caller.
• This fallback response is usually a default value, cached data, or an alternative service.
• The purpose of the ‘OPEN‘ state is to protect the system from cascading failures when the operation continuously fails.
• The circuit breaker remains in the ‘OPEN' state for a specified “retry timeout” duration, during which it does not forward requests to the operation.

HALF_OPEN State

• After the “retry timeout” period expires, the circuit breaker transitions to the ‘HALF_OPEN‘state.
• In the ‘HALF_OPEN‘ state, the circuit breaker allows a limited number of test requests (often just one) to the operation to determine if it has recovered or is still failing.
• If the test request(s) succeed, it indicates that the operation is likely functioning correctly again, and the circuit breaker moves back to the CLOSED state.
• If the test request(s) fail, it suggests that the operation is still not stable, and the circuit breaker moves back to the OPEN state.
• The 'HALF_OPEN‘ state acts as a trial phase to check if the operation has recovered before fully resuming normal operation.
• The ‘HALF_OPEN‘ state acts as a trial phase to check if the operation has recovered before fully resuming normal operation.

The circuit breaker transitions between these states based on the health of the operation and the predefined thresholds for failures and retry timeouts. It aims to provide better responsiveness to failures, protect the system from the consequences of a continuously failing operation, and restore normal operation once it becomes stable.

Here’s an architecture diagram illustrating the Circuit Breaker pattern:

In this diagram, we have a client that communicates with a remote service. The Circuit Breaker pattern is introduced between the client and the service to provide fault tolerance and resilience.

Here’s how it works:

1. The client initiates a request to the service through the Circuit Breaker.
2. The Circuit Breaker acts as a proxy and intercepts the request.
3. The Circuit Breaker maintains an internal state to track the health of the service.
4. If the service is healthy, the Circuit Breaker forwards the request to the service.
5. If the service responds successfully, the Circuit Breaker allows the response to pass back to the client.
6. If the service responds successfully, the Circuit Breaker allows the response to pass back to the client.
7. After a certain number of consecutive failures or other defined criteria, the Circuit Breaker “trips” and enters an open state.
8. In the open state, the Circuit Breaker prevents further requests from reaching the failing service. Instead, it immediately returns a predefined fallback response to the client.
9. The fallback response can be a default value, cached data, a friendly error message, or an alternative service.
10. While the Circuit Breaker is open, it periodically allows a test request (or a few test requests) to reach the service to check if it has recovered.
11. If the test request(s) succeed, the Circuit Breaker transitions to a half-open state, allowing a limited number of real requests to the service to verify its stability.
12. If the test requests in the half-open state are successful, the Circuit Breaker resets to the closed state, and normal request flow is restored.
13. If any of the test requests fail, the Circuit Breaker re-enters the open state and continues to return fallback responses.
14. The Circuit Breaker periodically retests the service to see if it has recovered, and the cycle repeats.

By incorporating the Circuit Breaker pattern into the architecture, failures and slow responses from the service are detected and handled gracefully. The pattern protects the client from unnecessary calls to a failing service, provides faster error handling, and prevents cascading failures throughout the system.

It’s important to note that the architecture diagram can vary depending on the specific implementation and tools used for implementing the Circuit Breaker pattern in Microservices. The diagram presented here provides a high-level representation of the pattern’s concept within a distributed system.