Circuit Breaker Pattern for Microservices
Only the concept, Hystrix will follow later
In this blog, I will be explaining the need for circuit breaker pattern in microservices and how this circuit breaker pattern works. The implementation of this can be done with Hystrix which I am planning to discuss in another blog.
Before going to the pattern, I recommend you to understand what microservices pattern is. I will be just pointing the points that add value to the circuit breaker pattern. Then introduction given for the microservices is for the purpose of explaining circuit breaker pattern, not to give an unerstanding about microservices.
Microservices
There are many benefits using the microservices architecture. This is a concept where we break down a monolithic application into several small services that focus on a particular domain. This brought many benefits to the developers
- low coupling
- re-usability
- business agility
- distributed cloud-ready applications
So once we break down into several services then we will be forced to make several calls to the other services. In the monolithic application, those calls will be in-memory calls and in microservices, those calls will be remote calls 😮. This is a point where we needed this circuit breaker pattern.
Life without circuit Breaker
You don’t feel any benefit from the circuit breaker pattern if everything goes right. A rest template will do everything you need. But if a service goes down, then you will see the all kind of reviews for your application.
Let’s assume a service is down in your microservices (let’s say service B). Now a client is making a call to service A. Then service A will get the results from service B, without which service A cannot complete the request. So the client made a call to service A and service A made an internal call to service B. But the service B is down. So service A will wait for service B until the timeout. Then service A will display the most irritating error message with a number 500. Making the client read this error message after making him/her wait for a long time will be the most irritating thing a developer can do.
So this scenario makes two questions.
- What can we do to solve this issue? are we going to fix service B?
- Why this is important in microservices?
To answer these questions, first of all, we are not going to do anything with service B, most of the time we will not have access to service B. But what we are trying is to print the error message without making the client wait. Then to answer the second question, microservices create many independent services which will increase the number of services in an single application. The risk of a service failing in a microservices architecture is very high with the number of independent services. If you have many services there is a huge chance for a service to fail. Then on the other hand microservices will make many inter-service calls which will have the direct impact from the case mentioned above.
Circuit Breaker pattern
What a circuit breaker does is, it accepts failures and track those failures. Circuit breaker wraps a function call with a monitor where the monitor will be tracking the failure. The logic behind circuit breaker pattern is that it tracks the status of the needed service. If the service is in the failed stage, circuit will send the error message without making a call. If the service is up, then breaker forwards the call to the needed service.
States of the circuit breaker
Closed state
This is the stage similar to the closed stage of the electric circuit breaker. Electric circuit breaker allows current in the closed stage. Likewise, circuit breaker will make the remote call when it is in the closed state. This state implies that the service is up and running(properly). Then if the number of error responses from the needed service passes a threshold limit, the circuit breaker will be tripped (ie: goes to the open stage).
Open state
In electrical circuit breakers, this is the state where circuit breaker will not let the current to pass. That's the same concept that we are implementing. In this state circuit breaker will not make the remote calls. Since the requests failed more than the threshold, we will know that the service is not working properly. Actually, the result need not be a 500 error message to the client. With the circuit breakers, we implement a fallback method which will handle the case if the needed service is down. So in the open state, the circuit breaker will trigger the fallback method. After a considerable time, the circuit breaker will go to half-open state.
Half Open State
This is a stage that the circuit breaker takes after spending some time in the closed stage. During this stage, the circuit breaker makes a remote call to the service. If the request fails, the circuit breaker will go to the open stage. If the service gives the proper response, the circuit breaker will go to the closed stage. So with a specified time period, the circuit breaker will check the service and decides which state to go.
Fallback Method
This is the method we will follow if the needed service is down. These methods may differ from application to application with their requirements. If the service is down, we can display an error method, we can use the cached data, we can request any other service etc.. This can be a method that we prefer to follow in case of failure.
Conclusion
Circuit breaker pattern will handle faults gracefully. It does not make the client wait for the internal server error and helps us to provide the better user experience. On the other hand the server might be down with the load. If we continuously send requests to that server, it will make the things worse. So this pattern will reduce the load of the needed service. This is very much needed in the micro services pattern since we will be dealing with many services and many remote calls. The most famous tool to implement this pattern is the Hystrix from Netflix. The implementation will be discussed in another blog.