Showing posts with label MIcroservices. Show all posts
Showing posts with label MIcroservices. Show all posts

Saturday, June 15, 2019

Circuit Breaker and Microservices Architecture

Circuit Breaker and Microservices Architecture 

In this article, I’ll talk about the Circuit Breaker pattern which is widely used in Microservices but before jumping to Circuit breaker design pattern or microservices. Let’s first understand the requirement so that you should know where we can use it in our application and Of Couse, How 😊

Let’s understand it with the real scenario as It’s already June month and we know there are so many online summer sales is going to start where they will offer you a various type of deals on their products.

And as we know most of the online portal has upgraded their application arch from Monolithic design to Microservices like Amazon, Flipkart, Snapdeal and so on and with that their each service will be running as an independent micro-services in the cloud like Authentication Service using which a user can be logged in to the application, Product Detail Service, Billing Service, Price Service, Card Services, etc.

Now just imagine the scenario where millions of users are doing online shopping on some online portal and because of load or some other technical issue, their price services goes down for some time. So, what will happen over here if a customer can’t order anything?

From a business point of view: it will give the bad impact of the sales as well as it will also decrease sales. Right?

From a technical point of view: All the request going to Price Service will fail eventually and failure in one part of the system might lead to cascading failures and all the future request will be blocked until the timeout expires and there are high chances that these blocked requests might hold critical system resources such as memory, threads, database connections and so on. Consequently, these resources could become exhausted, causing the failure of other possibly unrelated parts of the system that need to use the same resources.

How to solve it?
One simple approach is to return the cached price if the price service goes down and the original price once the price system available.

How can we achieve the above solution?
We can achieve this approach easily by implementing a circuit breaker pattern that allows a fallback when one of the applications goes down.

The concept of Circuit breaker is very similar to automatically operated electrical panel switches of our home which goes down after the fault detected (either an electrical storm or power surge) and can be reset (either manually or automatically) to resume normal operation after the fault is involved.

The Circuit breaker pattern helps to prevent such a catastrophic cascading failure across multiple systems. It allows us to build a fault-tolerant and resilient system that can survive gracefully when key services are either unavailable or have high latency.

The concept of circuit breaker is straightforward and has three distinct states:
  1. Closed: When everything is normal, the circuit breaker remains in the closed state and all calls pass through to the services according to its lifecycle until it encounters a failure and when the number of failures exceeds a predetermined threshold the breaker trips and the circuit breaker will change the state to the Open state.
  2. Open: When the breaker in its open state then the request will not go the service but will acts as a backup plan like throwing error directly or in our case, get the response from the Cache service.
  3. Half-Open: A limited number of requests from the application are allowed to pass through and invoke the operation. If these requests are successful, it's assumed that the fault that was previously causing the failure has been fixed and the circuit breaker switches to the Closed state (the failure counter is reset). If any request fails, the circuit breaker assumes that the fault is still present so it reverts back to the Open state and restarts the timeout timer to give the system a further period of time to recover from the failure.

  1. Helps to add logic for a fault tolerant system like try to get the data from some other source or from the cache.
  2. Handle downtime and slowness of services gracefully
  3. It will switch back to the main service once the service is again available automatically.
In my next blog, I'll talk about how can we implement circuit pattern using Spring Boot.

How TOPT Works: Generating OTPs Without Internet Connection

Introduction Have you ever wondered how authentication apps like RSA Authenticator generate One-Time Passwords (OTPs) without requiring an i...