by 
In the last post, I have briefly touched down on the circuit breaker and provided a real-life implementation using Spring Cloud Netflix Hystrix. The objective of this post is more about discussing the benefits and drawbacks of using a circuit breaker in your technology stack. So in contrast to the previous post that was more hands-on style, this post focuses on the architectural choice of using circuit breaker.
Circuit breaker benefits
A good way to start this topic is to try answering this question:
Isn’t circuit breaker is overkill when we can simply set a
timeoutfor requests or usetry...catchorif...then?
The answer to the above question depends on how the circuit-breaking is applied.
If the idea is just to close the circuit permanently or check the failure case by case, then using a circuit breaker may not make much of sense.
To elaborate better let’s think about an example.
For example, we have a service that generates random numbers (RD). And we have another service (IX) that does a REST call to RD to get a random number.
There is a business requirement in which if IX fails to get a number from RD, it needs to generate the random number by itself.
Well in such a scenario, I honestly don’t bother to implement a circuit breaker. I only wrap calling RD in try...catch. Then inside of catch block, I call the internal random generator method.
Why? because we are not concerned about the degradation of the IX service and also not getting a random number from RD is not mission-critical.
However, if we want to care about latency and would like to keep the service performance degradation minimal, it is better to use the circuit breaker. Means, if a certain number of calls failed, close the circuit and use another channel to fulfill the request. Or fail gracefully.
Besides that, we can set a threshold for response time. So if the dependent service for some reasons got slower, we can close the circuit.
Moreover, when using the circuit breaker we regulate the pressure on the dependent service. In other words, being a good consumer by not starting to bombard (DDOSing) the service once it has recovered. And cause the service to go down again.
Finally, the best benefit of using circuit breaker, in my opinion, is the ability to automatically open the circuit. Whenever everything is alright. This reduces the overhead of writing a separate routine to check whether the dependent service is stable/accessible or not.
Circuit breaker disadvantages
We discussed the benefits. Let’s focus on the drawbacks for a short while.
The first drawback of using circuit breaker is adding complexity to codebase. Even though most of the frameworks available keep the pollution minimal, still more code needs to be written and breaks the natural workflow. Not to mention that it makes writing tests very difficult.
The circuit breaker is a workaround to a bigger problem if the dependent service is maintained by you. I believe if you maintain the dependent service and you constantly having an issue which needs the circuit to be closed, then it is better to do something about the faulty service. Investing time and energy on solving the issues of the dependent service pays off much better. Because if you add a new consumer, then the circuit breaker logic should be implemented in the new service as well. This is not maintainable. Better solve the issue at the root.
Keeps bugs hidden. This relates to the previous point. Since at the time of crises the circuit closes, is most likely that nobody detects the problem. Hence, many bugs may stay hidden which otherwise would have been discovered if there was disruptions in the operation.
To conclude this post, I’d like to reiterate that using a circuit breaker or not is not a general decision. It should be considered case by case. In some cases, it is overkill, in some not. Anyhow, the business requirement plays a very important rule in the decision-making process of using a circuit breaker or not.
