Resilience4j at a Glance

Reading Time: 4 minutes

Resilience4j at a Glance

Scope of this article is applications based on microservice architecture.

Let me begin with a question, what is most important non-functional requirement from any application? Undoubtedly the answer of this question will be ‘Robustness’. This means applications must behave reasonable with respect to adverse scenarios. Against all adverse scenarios application needs to take either corrective action or redirect to reasonable action or application flow. It is very much required to understand about those adverse scenarios.

  1. Out of all one or more than one microservice is broken or out of order.
  2. Need to manage user traffic by fixing number of requests in specific time.
  3. Need to manage user traffic by fixing specific number of concurrent requests.

There is no dispute on need of above functionality in application to achieve robustness and resiliency in working of application. At some extent Hystrix from Netflix could resolve the issue but not all. Also, Spring Cloud Hystrix project is deprecated. So, under the umbrella of ‘Spring Cloud Circuit Breaker’ Resilience4j is introduced.

Now let us consider above mentioned scenarios in detail and how Resilience4j maintains resiliency.

1. Out of all one or more than one microservice is broken or out of order,

To understand let us consider below implementation of microservices,

In all favorable conditions, nothing to worry but what if any of microservice fails or does not behave as per expected functionality? For time being let us consider below negative scenario,

As per above diagram, Microservice MS2 is non-operational . In flow, microservice MS-1 will not be able to get expected response from MS-2 and expected functionality remains unfulfilled. resilience4j-circuitbreaker will help you to handle such scenarios.

So below are the steps you need to manage resiliency in Springboot,

a) Include dependency in maven similar to below,

b) Setting property value in application.properties file

If you want to call fallback method if failure rate is 60% or more,

more properties values can be set as per need of application behavior.

c) Writing fallback method,

2. Need to manage user traffic by fixing number of requests in specific time,

There are scenarios when we need to restrict number of requests within some specific time. One of the use cases we can consider here which is of provisioning of DB connection. If we want to provision only 100 connections pers second and for next connection after 100th connection application needs to wait for 5 second, below implementation will help to achieve this purpose,

a) Include dependency in maven similar to below,

b) Setting property value in application.properties file,

Below values will ensure that service MS1 will only allow 100 requests in 5 seconds,

c) Writing annotation on REST method,

Above implementation will put a cap of 100 request in 5 seconds. This approach will help to prevent against,

  • Web/data scaping.
  • Brute force attacks.
  • DoS(Denial-of-Service) and DDoS (Distributed Denial-of-Service) attacks.

3. Need to manage user traffic by fixing specific number of concurrent requests,

This is nothing but implementation of bulkhead design pattern. This implementation will be required when we want to distribute concurrent requests evenly among multiple but same microservice. This means if we are anticipating 1000 concurrent request for particular functionality and we have 4 instances of microservice for that functionality. In such scenarios we need to distribute 1000 concurrent requests among 4 available instances.

Below implementation will consider only 25 concurrent requests per instance.

a) Include dependency in maven similar to below,

b) Setting property value in application.properties file

Below value will ensure that service MS1 will only allow 25 concurrent requests,

c) Required annotation for REST method to achieve this will be like below,

So, this is tolerant of failure. We can define or restrict number of request as per capacity of local resources to operate within tolerance limit. This will restrict failure by passively transferring responsibility to other microservices.

Written by 

Abhijna, A seasoned technologist holding 19+ years of industry experience. During major part of his career, he worked for finance domain. I-flex solution, Credit-Suisse, J P Morgan and Barclays Global Service Centre are the organizations where he had contributed his technical skills in finance domain. He is accomplished technologist in context of technologies like Java/J2EE platform covering Core Java, JSP/Servlet, Spring, Hibernate and Struts Framework. He knows REST Web Services, Axis2 (SOAP Engine), Informatica 8.6 and Pentaho ETL tools as well. Also, possess working knowledge of Micro-Services, Kafka and AWS as well. Since several years he had demonstrated successfully his technical ability in the form of architectural and leadership roles. Abhijna is very comfortable in ADM (Architecture Development Method) and Enterprise Continuum. Requirement Analysis and Design using UML are also part of his skill set. Abhijna is Certified TOGAF enterprise architect & has good hold on knowledge of PMBOK. He has proven track record of executing projects, interfacing with the customers, requirement analysis, transforming requirements to design and project implementation. He has successfully delivered projects in Financial Services, Investment Banking, Credit Card and Agriculture domains. Apart from this he has experience in risk-management with respect to BASEL-II norms. He is comfortable on financial topics like Bonds, Fixed Income, Corporate Finance, Financial Reporting and Analysis, Quantitative Methods etc.. During entire career in IT industries Abhijna has managed team from the size of 4 to 80 resources within one and multiple geographical locations. Abhijna holds very nice level of technical and management skills which makes his leadership actions more effective.

2 thoughts on “Resilience4j at a Glance6 min read

  1. Nice blog Abhijna, for the cases that you mentioned, could you also specify
    1. If the MS2 is not responding and the circuit breaker kicks in the requests go to the fallback mechanism, how and when does the circuit close again? What happens to the requests which have gone to the fallback mechanism in the meantime
    2 &3. Similarly for these scenarios what happens when the number of requests exceed 100 and 25 concurrent users. Are those dropped?

    1. Hi Vikas,
      It’s really encouraging when someone like you put such comments and motivates to explore more.
      1) Here property ‘waitDurationInOpenState’ plays role to make circuit OPEN to HALF-OPEN state. This means circuit will remain OPEN for specified duration and then moves to HALF-STATE. Once circuit is HALF-OPEN, request will be thrown to unhealthy service to verify health of service.
      To decide service is healthy or not ‘ringBufferSizeInHalfOpenState’ property can help to understand same. So, if value of ‘ringBufferSizeInHalfOpenState’ is 5, circuit will not pick OPEN state.
      2) Case 2 : RateLimiter rejects the call which are after 100th call in 5 seconds.
      Case 3 : It depends on selection of implementation. If we have picked ‘Semaphore’ , request will be rejected if microservices are already handling 25 requests. And, if we have considered ‘FixedThreadPoolBulkhead’, new request will wait till microservice would have room to accommodate them.
      We can have fallback method for case 3 & 3 as well to handle negative scenario.
      I hope, above explanations helped you to resolve your queries.
      Intention of this blog was just to provide glimpse of resilience4j and so I haven’t used any complicated terms and scenario in it.
      I may come up with detailed blog in future.

Comments are closed.

%d bloggers like this: