Circuit Breaker Pattern Microservices
The Circuit Breaker design pattern serves as a mechanism to prevent recurring failures. These failures may stem from various factors, such as maintenance, temporary issues in external systems, or unexpected system challenges.
For instance, consider a scenario where our API is interfacing with an external service, and this external service experiences a failure. In such a situation, we aim to avert recurrent failures and eliminate the need to wait for a connection timeout each time.
Therefore, we can employ a circuit breaker to assess the availability of the external service instead.
States of circuit Breaker
- Closed
- Open
- Half Open
Closed State
A closed state in a Circuit Breaker is analogous to an electrical circuit in which your service initiates an external API call. This API call is subsequently routed through the Circuit Breaker, which in turn connects to the external service. Subsequently, it retrieves and returns the response from the external service.
Open State
An open state in a Circuit Breaker occurs when the external API call is not made, and the Circuit Breaker promptly sends an error response. This state is triggered when the external service consistently returns errors over a series of requests, surpassing the predefined threshold. As a result, instead of continually reaching out to the external service, the Circuit Breaker responds with an error message.
Half Open State
When the Circuit Breaker is in an open state, it will, after a specified time interval, attempt to communicate with the external service. If it receives a successful response, the state transitions to closed. However, if it doesn’t receive a successful response, it reverts back to the open state.
Here’s how a circuit breaker typically works:
- Initially, the circuit breaker is in a “closed” state. In this state, it allows requests to pass through to the external service. It monitors the responses from the service to check for any signs of failure.
- While in the closed state, the circuit breaker continually monitors various metrics related to the external service, such as response times, error rates, or timeouts. These metrics provide insights into the health of the service.
- The circuit breaker has predefined thresholds and triggers. If the monitored metrics breach these thresholds, indicating a potential issue with the external service, the circuit breaker transitions from the closed state to the “open” state.
- When in the open state, the circuit breaker prevents any requests from reaching the external service. Instead of allowing these requests to propagate and potentially exacerbate the problem, the circuit breaker intercepts them and returns a predefined error or default response to the application. It effectively “cuts off” the connection to the troubled service for a period of time to allow it to recover.
- While in the open state, the circuit breaker typically has a timeout period. Once this period elapses, the circuit breaker transitions to the “half-open” state to test the service’s availability. During the half-open state, the circuit breaker allows a limited number of test requests to pass through to the service.
- In the half-open state, the circuit breaker sends a limited number of test requests to the service to determine if it has recovered. If these test requests are successful and the service appears to be functioning correctly, the circuit breaker transitions back to the closed state, allowing normal traffic to resume. If the test requests still fail, the circuit breaker returns to the open state and continues to monitor the service.
Sources
