Circuit Breakers in Microservices
Circuit Breaker is a pattern in Microservice came from Electrical Circuit Breaker.
Why should I read this Article?
- What is Circuit Breaker?
- Need for Circuit Breaker
- Different States of Circuit Breaker?
- Working of Circuit Breaker
Before starting explaining, I would like to say that Everything Fails so don’t avoid it but embrace it.
Circuit Breaker: The basic idea of the Circuit Breaker pattern is to monitor your application services failures. And can be done by wrapping a protected function call in a circuit breaker Object and when failures do happen then manage it in order to minimize the impact of those failures on your applications.
This pattern allows you to build a fault-tolerant and bottom-up resilient system that can survive when services are either unavailable or have high latency.
Let me explain you in simple language by considering the Circuit breaker of our house. We all have a fuse for our house and when the voltage is high then it trips down so that all the electric circuits and appliances at home are safe without being getting damaged.
Problem :
Modern Applications have lots of dependencies. A lot of things are happening at the backend of which, the end customer is unaware in these applications. As the application is in a distributed system so, surely anything can happen and will, go wrong. There could be many reasons for that, like rebooting router, network congestion, or a request just failed, and so on. Sometimes these problems get solved quickly but sometimes not.
Think you, as an end customer who is trying to access some website but the site is showing progress/loading bar and after waiting for a long time you get an error message. Believe me, nothing is more frustrating than this.
The solution, just for the above Failure :
- Failover Cache: advantage is that the thread will get free soon and the temporary latest result can be shown 🤫 to the customer.
- Retry: Retrying is needed but while retrying continuously we may face the problem of getting out of threads from the thread pool as all the threads are used 🙄.
Solution: Circuit Breaker
So, now we will put these two ideas of Cache and retry mechanism in the circuit breaker concept and explain them in the section “How Circuit Breaker works”.
States of Circuit breaker/life cycle of Circuit breaker:
- Closed :
- Open
- Half-Open
Working Of Circuit Breaker:
In the circuit breaker pattern, there are three actors, the client(Service A), the circuit breaker (request interpreter) and the Supplier (service B). While explaining the Circuit Breaker system, I am taking Application frontend separate from Circuit breaker system.
CASE 1. When all services are running fine as expected: the service communicate via our request and response interceptor (Circuit breaker) and the connection is closed which mean the connection is established.
CASE 2. When service B is unable to respond to Service A, the circuit breaker will go into “OPEN” state.
- Case 2.1: Use Cache, so that Customer will get the response even though the request is not directly coming from Service B (in our case)
- Case 2.2: Use the Retry mechanism but by providing threshold attempt and time-out. let’s assume at the beginning, service B is showing its unavailability and our threshold value, in this case, is 2 with a timeout of 20 secs, then after 2 attempts of trial, it will go into the OPEN state (meanwhile show cache value as a response to the customer) and after 20secs, will try to reconnect the circuit.
But look here, we are not sure whether the service recovered or not so to check the availability of service B, instead of sending the connection into the Closed state, it will be sent to half-Open.
CASE 3. Half-Open: In this state, it’s not really open, but it will let one call through, just to test if the external service is working again. If the call fails, the circuit breaker immediately switches back to the open state, and the open state timeout period starts again and the timer is not reset. If the call succeeds when the circuit breaker is in the half-open state, the results will be returned to the caller as if the circuit breaker was closed, and the circuit breaker switches to the closed state.
You can also make the half-open test smarter by having it test against the health endpoint that is specifically made to deal with health requests, instead of making the actual call. It all depends on the service that you are abstracting with the circuit breaker pattern. You can make the circuit breaker as intelligent as you need.
We can configure the threshold value of attempts and timer for timeOut while doing the implementation in our code.
See these three states as 3 signal lights will the same meaning.
Mainly we have 2 circuit breakers:
- Netflix Hystrix
- Resilience4j
For configuring spring boot with resilience4j, refer: https://resilience4j.readme.io/docs/getting-started-3
Hope, you enjoyed reading this article 😊.
