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.

#java #microservices #scala #tech blogs #java #resilience4j #resilient #retry