Reading Time: 2 minutes

Hi guys, I hope you are doing good. In this blog, we will be talking about one of the core modules of resilience4j: Retry. If you are not familiar with the resilience4j library then you can refer my last blog Bulkhead with Resilience4j. It would be a 2 minutes read.

What is Retry in API calls?

We use the Retry mechanism to make out the micro-services fault-tolerant or resilient. Many things can go wrong during inter or intra service communication. So, for handling such issues, the Resilience4j java library, provide a solution that helps us to build resilient and fault-tolerant applications. As the Retry keyword indicates, if the user gets an unexpected response from the resource then automatically again hit the resource. We can limit the no of times to hit the resource, by doing little configuration in the development code.

When to use Retry?

In service-based architecture, generally, services are talking to each other and that can be cloud to cloud or to the other service in the same cloud environment. Then in the cloud to cloud, we can’t avoid network glitches or temporary service down, etc. So, there is a specific condition where we can use the Retry mechanism.

• Calling an HTTP service from another REST endpoint.
• Calling a web service.
• No or slow responses due to a large number of requests towards the resource(database or service).
• In pub/sub mechanism

There are some important points which we need to keep in mind before using it. which are as follows –

• We should not use retry for each type of exception. For example bad requests etc. Should use only when you think that it may meet your requirement.
• While using retry, we should also take care of the idempotency principle. Attempting the same request again & again may cause duplicate stream in the application.
• We should keep the number of retries not more than 5 because it can make things worse. For example – On an overloaded server, If we try to hit the request again & again then it will make things worse or overburden the server.

Retry with Spring boot

Step -1. Add the custom configuration of the retry according to use-case in the application.yaml.

Here maxAttempts =5, means the maximum number of retry attempts. Let’s say if we got the expected response after 3rd attempt then the retry mechanism will stop otherwise it would hit the target resource 2 more times,waitDuration=1000, means the interval time between the retry attempts.

Step-2. Create a controller class that will have the following endpoint.
Here, for demo purposes, we will hit the apigee proxy from the endpoint /register/seller.

Step-3. Here service implementation is wrapped with @Retry annotation. The annotation supports the fallbackMethod attribute and redirects the call to the fallback functions after the number of retry calls exceeds maxAttempts attribute. If that happens then the response from the retryfallback method will be returned as a response.

That’s all for this blog, I hope you like this blog. If you have any queries or want to know more about it, you can add your queries in the comment section. I will be happy to answer them.