Introduction to Resilience4j Circuit Breaker

In a microservice architecture, There are multiple services connecting threw each other and there is always the possibility that the other service being called is unavailable or unable to respond. So, what can we do then? Here resilience4j circuit breaker comes into the picture

INTRODUCTION

Resilience is essential for any system that needs to function effectively, and the resilience4j Circuit Breaker is no exception. The resilience4j Circuit Breaker is a widely-used pattern in software engineering that helps ensure the resilience of a system by handling failures and preventing cascading failures.

WHAT IS A CIRCUIT BREAKER

The resilience4j Circuit Breaker is a design pattern that works by monitoring the state of a particular service or resource. It is designed to detect when a particular service is experiencing many failures or when the response time is too slow. When the circuit breaker detects such an event, it will “trip,” which means that it will stop sending requests to the service or resource and instead return a predefined default response

CIRCUIT BREAKER STATE

It has 3 states Closed, Open, and Half-Open

In the Closed state, the circuit breaker allows requests to pass through to the service or resource. If the service or resource experiences many failures or slow response times, the circuit breaker will trip and move to the Open state. In the Open state, the circuit breaker returns a predefined default response to incoming requests. This helps to prevent further requests from being sent to the service or resource until it has recovered.

After a certain period, the circuit breaker will enter the Half-Open state. In this state, the circuit breaker allows a limited number of requests to pass through to the service or resource to check if it has recovered. If the service or resource is able to handle the requests without errors or slow response times, the circuit breaker will move back to the Closed state, allowing all requests to pass through as normal. If the service or resource continues to experience issues, the circuit breaker will trip again, returning to the Open state.

Prerequisites required for implementation in Springboot

The library that offers circuit breaker features is Resilience4J. As an example, First, we will create a spring boot REST API project with the required dependencies as shown below

 <dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-spring-boot2</artifactId>
 </dependency>
 <dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-reactor</artifactId>
 </dependency>
 </dependencies> 

After this, we will create a rest API to start simulating a circuit breaker.

private static final String CUSTOMER = "customer";
@GetMapping
@CircuitBreaker(name =CUSTOMER , fallbackMethod = "customerFallbackMethod")
public String customer(){
 String url = BASE_URL + "v2";
 return   restTemplate.getForObject(url,String.class);

 }

 public String customerFallbackMethod(Exception e){
 return "The shopkeeper is not avaliable for taking order";
 }

An API with a circuit breaker is simply marked using the @CircuitBreaker annotation followed by the name of the circuit breaker. The fallback method is a mechanism that allows you to define an alternative code path to be executed when a failure occurs in a protected operation. The fallback method acts as a fallback or a fallback behavior when the primary operation fails due to an exception or other error conditions. The @CircuitBreaker annotation often provides a fallback behavior, which is a predefined alternative action or behavior that is executed when the circuit breaker is in the open state and requests are blocked. This fallback behavior can be used to provide graceful degradation of functionality or to provide an alternative response to the calling code when the remote service is unavailable Below are config used to add it to the application.properties file

# Resiliece4j Configuration

resilience4j.circuitbreaker.configs.shared.sliding-window-type=count_based
resilience4j.circuitbreaker.configs.shared.sliding-window-size=5
resilience4j.circuitbreaker.configs.shared.failure-rate-threshold=40
resilience4j.circuitbreaker.configs.shared.slow-call-rate-threshold=40
resilience4j.circuitbreaker.configs.shared.permitted-number-of-calls-in-half-open-state=1
resilience4j.circuitbreaker.configs.shared.max-wait-duration-in-half-open-state=10s
resilience4j.circuitbreaker.configs.shared.wait-duration-in-open-state=10s
resilience4j.circuitbreaker.configs.shared.slow-call-duration-threshold=2s
resilience4j.circuitbreaker.configs.shared.writable-stack-trace-enabled=true
resilience4j.circuitbreaker.configs.shared.automatic-transition-from-open-to-half-open-enabled=true

resilience4j.circuitbreaker.instances.customer.base-config=shared

The above configuration here we used for the implementation

Let’s look at the following configurations:

• Sliding-window-type: In this, we are using the count-based type, it will cut the circuit or will move it to an open state for each request
• Sliding-window-size: In this, we will record the last number of requests and will make a circuit from a cut or open state and we will keep track of the last 5 calls on service
• Slow call rate threshold: This is a property that allows you to specify a threshold for the rate of slow calls. Slow calls are calls to a remote service that takes longer than a specified duration. When the rate of slow calls exceeds the specified threshold, Resilience4j can trigger a SlowCallRateThresholdExceededEvent to alert the application that there is a problem with the remote service.
• Permitted number of calls in the half-open state: This property defines the maximum number of requests or events allowed to pass through the circuit breaker in the half-open state. Once this limit is reached, the circuit breaker transitions back to the open state if additional requests are made
• Max wait for the duration in the half-open state: This is a property that specifies the maximum duration for which a circuit breaker can remain in the half-open state before transitioning back to either the closed or open state, depending on the outcome of the requests made during the half-open state
• Wait duration in the open state: The wait duration in the open state refers to the time that a circuit breaker remains in the open state after tripping the failure threshold. During the open state, the circuit breaker prevents requests from passing through to the remote service and returns a failure response or raises an exception immediately without attempting to execute the request.
• Writable stack track: This is a property that determines whether writable stack traces are enabled for exceptions thrown by the circuit breaker. When set to true, the stack trace of the original exception that caused the circuit breaker to open will be preserved in the exception thrown by Resilience4j. When set to false, the stack trace of the original exception will be lost and replaced with the stack trace of the Resilience4j exception.
• The automatic transition from open to half open enable: This is a property that determines whether the automatic transition from the open state to the half-open state is enabled for the circuit breaker. When set to true, the circuit breaker will automatically attempt to transition from the open state to the half-open state after the waitDurationInOpenState has elapsed. When set to false, the circuit breaker will remain in the open state until manually reset.
• Ignore Exception: This property specifies a list of exceptions or error types that should be ignored by the circuit breaker. Requests resulting in these exceptions will not be counted as failures, and the circuit breaker will not trip based on these exceptions.
• Record Exception: This property specifies a list of exceptions or error types that should be recorded by the circuit breaker. Requests resulting in these exceptions will be counted as failures, and the circuit breaker will trip based on these exceptions.
• Failure-rate-threshold: In this, we will get the total number of failed calls and will cause the state to open state as per the configuration 2 out of 5 failed calls will change the state from cut to open state
  For other configurations, please refer to the Resilience4J documentation.
  

The circuit breaker pattern provides several benefits to software developers. First, it can help prevent failures from propagating through a system, thereby reducing the impact of a failure on users. Second, it can help improve the overall stability of a system by providing a way to detect and isolate errors. Finally, it can help improve the performance of a system by reducing the number of requests sent to a service that is known to be failing.

CONCLUSION

The Circuit Breaker pattern is an important tool for building resilient systems that can handle failures and prevent cascading failures. By monitoring the state of a service or resource and tripping when necessary, the circuit breaker provides a way to ensure that systems can handle issues and recover quickly