Resilient Microservice Design With Spring Boot — Retry Pattern

3 min readOct 25, 2020

In this article, I would like to show you yet another design pattern — Retry Pattern — for designing resilient microservice. Retry pattern works great with Timeout pattern. This is second article in the Resilient design patterns series. If you have not read the previous article on Timeout Pattern, I would suggest you to take a look at the first article here.

Need For Resiliency:

MicroServices are distributed in nature. It has more components and moving parts. In the distributed architecture, dealing with any unexpected failure is one of the biggest challenges to solve. It could be a hardware failure, network failure etc. Ability of the system to recover from the failure and remain functional makes the system more resilient. It also avoids any cascading failures.

Why Retry?

We had discussed the importance of having timeout when the services depend on each other. Even though timeout pattern works fine, It does not solve the problem fully. That is, either we get the response within 3 seconds in the very first attempt or we send the empty response assuming we will not get the response. Sometimes when google.com does not work for us, we just do not give up. we simply refresh the page once assuming things will work and it does most of the times. Intermittent network issues are very common. In real life, we might be running multiple instances of RatingService. One of the instances could be having the issue — so it does not respond properly to our request, If we retry the request, the load balancer could send the request to a healthy node and get the response properly. So with Retry option, we have more chance for getting the proper response.

Sample Application:

Source code is available here.

As this article is simple continuation of the previous article on Timeout Pattern, I am going to use the same application. Here we would be introducing Retry. that is, if we do not get response from the Rating service, We just send one more request if we have any luck!

Rating — MicroService:

RatingController:

I am making below changes in the rating controller. Instead of hard coded delay of 30 seconds, I generate some random number between 10 — and 5K and delay the response accordingly to simulate intermittent application slowness.

Product — MicroService:

We would start with adding below maven dependency for the product service.

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aspects</artifactId>
</dependency>

Enable Retry — Add the @EnableRetry in the main class for the service

@EnableRetry
@SpringBootApplication
public class ProductServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(ProductServiceApplication.class,  args);
    }

}

Modify the RatingServiceImpl of Product Service as shown here.

getRatings method is responsible for getting the response from the RatingService. If it takes more than 3 seconds, It will throw SocketTimeoutException. By using @Retryable annotation, in case of SocketTimeoutException, we would be trying one more time with 1 second delay.
Even after 2 attempts, if we still do not get the response, to recover from the failure, we create another method with @Recover. It is responsible for telling the application what needs to be done when RatingService does not respond with in time. In this case, we create an empty response as usual.

When we run these services and send the request to the product service, it sends another request to the RatingService in turn. We retry couple of times when we do not get the response. So that any intermittent network related issues do not affect the core services behavior.

Summary:

Timeout Pattern ensures that issue with 1 service does not cascade to other services. Retry pattern works along with Timeout pattern by re-sending the request one more time to make the system more resilient and handle network related issues.

There are other design patterns which could handle this better along with retry pattern. Please take a look at these articles.

Happy learning 🙂