What is advantage of circuit breaker design pattern in API architecture?

Question

So sorry if this question is not fit for SO.

But I tried looking lot for answer.

I was studying Circuit Breaker design pattern, As I understand its used for making you API fault tolerance. Now what I am confuse is,

Let say I have API which calls payment api, and lets say I configured my circuit to open if 5 calls fail continuously.

Now as per circuit breaker design, I will route subsequent calls after opening circuit to fall back method. lets say next 5 calls, and on 6th call I will make a call to payment API if api is online I will close circuit.

But I dont find any advantage of this pattern, Like what is difference between catch block and circuit breaker.

And what can we do in fall back method? How can this help?

Mori

Answer 1

Our colleagues have already shown the advantages of a circuit breaker, so I'll concentrate on practical examples.

So, looking at your example, you have a flow that has to call a payment API> Let's assume its an "external" component. Without this call, the whole flow probably can't be considered as "successfully completed" (I understand you have some online process that has a payment as one of its essential steps).

In this case Circuit Breaker indeed probably won't be that useful unless as a fallback you store the payment command in some kind of intermediate storage and then "re-apply" the payment logic.

The whole point of a circuit breaker is to provide a reasonable fallback so that the flow won't be considered as failed if the fallback logic gets applied.

Here is another example where Circuit breaker has much more sense.

If you build a "netflix-like" portal and in UI there is a widget that shows "recommended" movies. The recommendation engine takes into consideration the movies you've seen / liked before. Technically this is an "external system"/microservice.

Now, what if the flow that populates the data for the UI, is not able to get the recommendations (for example, if the recommendation service is down), will you "fail" the whole flow? Probably not, maybe its better to show some "generic list" of recommended movies and let the user proceed to work with the application.

In this case, the Circuit breaker can be a good choice for implementing the call to external recommendation service.

Now, what's the difference between this flow and exception handling?

If the reason for the failure of that recommendation system is some temp network outage / Database slowness, probably its the best to give this service some time and not to try to call it over and over again, we should give it a chance to 'recuperate'. When we apply a circuit breaker, during the "open-circuit" period our code won't even try to call the server, directly routing to the fallback method.

A regular try/catch block, on the other hand, will always call the recommendation service.

So to wrap up, a circuit breaker is a pattern for fault tolerance as was stated in the question; its a tool which can be applicable in some situations, and irrelevant in other cases.

Stoic

Very well explained @mark. I understand how your fall back is important while considering circuit breaker. I understand its strategy pattern, with help of message queue we handle this in our system. But your example is very strong scenario. Thanks again for explanation – Mori

Does it mean, if there is no fallback, there is no value to implement circuit breaker pattern? – Forsta

During the "open circuit" phase, thr system does two things docferently: 1. Stops putting any "pressure" on the remote resource. 2. Calls a "fallback" in your code. If eigher of these two things are relevant - you can use a Circuit Breaker Pattern – Stoic

Answer 2

It is true that a great use of Circuit breaker is used to make an API fault tolerant.

Like what is difference between catch block and circuit breaker.

The major difference between a catch block and circuit breaker is the handling of the failure case. Suppose we are calling an api of an external system. Lets say, the api call failed.

1. If we use catch block, we will catch the Exception and call a fallback method. Next time we will call the same api and the external system is still down. So again this same cycle of events will occur. This will unnecessary bombard the suffering external system, consume system resources and also increase your api response time.

2. If we use circuit breaker pattern, then our first call fails and then we open the circuit. Next time we won't even call the external system, and directly follow the fallback pattern. Voila everything is handled!

And what can we do in fall back method? How can this help?

One good example for a fallback method is as follows. We have a payments system which routes payments to different payment gateways. Lets say we get an error from a particular payment gateway, then in the fallback method we can route it to different payment gateway.

You can also go through this article to understand more about this topic : https://martinfowler.com/bliki/CircuitBreaker.html

Orlina

Answer 3

The goal of this design pattern is to encapsulate the logic for handling unexpected, repeated errors.

The wikipedia page for this pattern has helpful sections explaining the types of situations where you would want to implement this logic to avoid making request that you expect to fail.

What is the advantage of this pattern

This pattern is advantageous when you run into a situation where you know a service will be unavailable, and you want custom behavior until the service comes back online. For example, during a database migration, it would make sense to circuit break requests into a queue until the migration has finished.

What is difference between catch block and circuit breaker

I think this difference is the difference between concept and implementation. Detecting the presence of a situation where you want to "open the circuit" might mean detecting errors in a catch block and counting them, as in your example. The handling is not limited to just errors, however.

In my example, the backend might inform the frontend that a migration is about to occur, causing an "open circuit" on the frontend until it receives a migration finished message.

Disclosure