A Discussion on Circuit Breaks in the Microservices Architecture
This article is authored by me, revised by Gabriel Lett Viviani and divided in three parts:
- A Discussion on Circuit Breaks in the Microservices Architecture ⬅ You are here
- A Discussion on Circuit Breaks in the Microservices Architecture: HttpClient Implementation
- A Discussion on Circuit Breaks in the Microservices Architecture: Policy Manager Implementation.
In them I would like to discuss about Circuit Breaks (CB) and how one can use and implement them when developing applications that take advantage of the Microservice Architecture. The general ideas behind this post are:
- Explain Circuit Breaks (off course);
- Talk about the benefits and hardships of using them;
- Demonstrate tradeoffs between some implementations and;
- Engage you readers in the discussion to suggest, share and criticize.
So, let’s begin!
Circuit Break is a relatively known pattern used with Microservices Architectures that anyone might have to implement (sooner or latter, and I truly hope it to be sooner for your sake..) when developing a new application or migrating an existing one to the Microservices Architecture.
Well, but still…what the hell is a Circuit Break?
A Circuit Break is a piece of software that acts like a switch (yes, you can relate it to the electrical switch)¹. What it exactly does is to interrupt the information flow between two components when one of them is malfunctioning².
In the microservices world we can say that a component is a microservice. An independent part of your code that runs by itself and has loose coupling with the rest or other parts of your entire system³.
As information goes from one microservice to another, one of this parts might malfunction or even go offine, making your application lose some functionality or even some features in the meantime it is down (I know, its pretty sad but better than your entire application being down).
At this point you maybe be asking yourself: “…ok, I know what a circuit break does. And thank god we have microservices so not our entire application goes berserk when some functionality goes south…but, why do I need a Circuit Break? If the service is down it will not respond, or will give an error and life goes on…”
If you were think that, in a way you are correct, but you did not consider the total impact on your application. The user indeed will get an error or will not be able to access some part of your system and life will go on, it is true. However, it takes time for your application to receive the error from that microservice that is malfunctioning. Nonetheless, this can and will affect your application performance (In some cases even when the user does not use that feature).
So it would be great if your application had some way to identify this malfunction and just not call the problematic piece returning automatically an error right?
TA-DA! Here comes CB to the rescue. With Circuit Breaks you can make your software detect fault components and by pass them based on rules defined by yourself, AI, or just guesses (sometimes it works, intuition supported by data is a strong tool…)².
Circuit Break Design
Now that we covered the WHAT and WHY of a CB, we move to the last part of this article. The HOW.
How does the circuit break work its magic? Well it has been designed to be a powerful pattern and yet a quite simple one. We usually wrap function calls to other services in the circuit break component. Making a composition on our designs.
The above Figure describes how a CB works in general. The initial state of a CB is Closed, what means that information is flowing from one service to another². After an specific event occurrence (usually a certain amount of tries that result in error) the circuit goes to OPEN state, which means that the information flow is interrupted². It stays there for a certain amount of time or even until another criteria is reached². Thus, during this period every call to the function returns a circuit break error². After this, the circuit goes to a Half Open State, when the function is called again it tries to contact the other service one more time². If it succeeds the CB goes to Closed state, otherwise it goes back to OPEN².
So in short the CB is preventing your microservice from even reaching a faulty component, failing faster and making your application a bit less susceptible to failures.
Thanks for reading this article, next we will discuss some of the benefits and possible implementations. As soon as a I complete the next article on this topic I will immediately post it here. If you want to collaborate just get in touch with me =)
References
- [1] Chris Richardson. Pattern: Circuit Breaker: https://microservices.io/patterns/reliability/circuit-breaker.html
- [2] Martin Fowler. (6 March 2014). CircuitBreaker: https://martinfowler.com/bliki/CircuitBreaker.html
- [3] Chris Richardson. Microservice Architecture: https://microservices.io/
