Circuit Breaker design pattern in software development

Circuit breaker design pattern in software development

Hello everybody, Today I’ll be talking about “Circuit Breaker”.
Indeed, A Circuit breaker is an automatically operated electrical switch designed to protect an electrical circuit from damage caused by excess current from an overload. It’s no jokes. This is the subject of electrical energy 101.

Circuit breaker, It’s not available to prevent the broken service, but not to make it worse than it was.

Circuit breaker

The circuit breaker in the role of software development is a design pattern for helping to detect the service whether still available or not. It will help to encapsulate our service that was repeatedly called to protect our downstream services, but how to tell people who request to handle you must do by yourself.

It can check the availability of external services. Maybe database or other external services that our application call.

When the circuit breaker detects any connections that fail or not available. It will block our application from accessing that service. Until the system is available.

Imagine, Our application connects to a database for ten thousand times in one second or 10,000 tps. Which makes our database “FAIL” but we don’t want to show the error to customer see that our system has failed. We want to handle those errors. Without having to wait for the connection timeout or “dire” from being hit more than this.

Implementation

Implement the circuit breaker design pattern need to request something to keep status of the connection. Which we need to close some logic of services to be called before the request. So that we can access the service that is still available or not.

So, The service that uses circuit breaker needs to operate something to allow the service to be accessed. Which we may do by using asynchronous.

In the event that our server has multiple nodes or multiple clusters. We may need to collect information for each node. Which node is ready to use, which node is not available. Which may be stored in the Redis or local cache depend on usage. Which do this in order to provide our service to check first. That request, is it available?

Circuit breaker design pattern in software development // iamgique

The different States of the Circuit Breaker

Circuit Breaker separate to 3 state

1. Closed: When everything is normal, the circuit breaker will be “closed” and the request will be sent to the service according to its life cycle. Until it encounters a failure the circuit breaker will change the state to “open”.
2. Open: When the circuit breaker has a state of “open”, the system will respond to the request, which will not request to the service that was actually requesting.
3. Half-Open: After the end of the period. The circuit breaker will change the state to “half-open”. To check if the system that is being requested is still failing. If the test still fails, the circuit breaker will return to state “open” again, but if successful the circuit breaker will change the state to “closed”

Example Implementation

Let’s try Circuit Breaker with Netflix Hystrix easily.

Beginning, I would like you to create a simple rest API first. Can use any language no matter if it’s Nodejs, python, go, c# or Java. Make it run on your local.

For example, I will use Node js + express to make a restful API method GET. Giving it to return json response “Hello World, iamgique”. Nodejs is easy for me, that why I use it.

restful API with Node js + express

response [“Hello World”,“iamgique”]

Now, let’s implement a Circuit breaker with Netflix Hystrix. I assume that everyone can set up a Spring project.

pom.xml // dependency of netflix-hystrix line 25–28

Application.java // Create SpringBootApplication, RestController, EnableCircuitBreaker

Activation circuit breaker
Create rest controller by giving request pass from API test-get
In order to call the service testCall ();

Create new service support to call from the controller before entering service. Will see that there is Annotation HystrixCommand this is a Circuit breaker. To return back to those who request that “Service unavailable please try again”. When the service will call is not working http://localhost:3000/test

After Implement

Let’s test, Try to run service 1 that we have implemented and run Project hellocircuitbreaker then try to call http://localhost:8080/test-get. Will get the picture.

http://localhost:8080/test-get

Try to “Close” service and try to request again.

http://localhost:8080/test-get

Will see that the response has changed. After we do the circuit breaker.

Conclusion

I think many people would probably use a circuit breaker before. Just don’t know that this is a design pattern as well. It just serves to check which will not be more disastrous than this. And then check whether it has failed or not. If success, then returns to normal use.

The circuit breaker advantage is to prevent people from repeatedly requesting downstream services while in trouble. In order for the service below to have time to fix or to recover itself. In the case that the load is too large to cause the process to fail.

For micro service architecture should be monitored to know the status of all services whether “open” or “half-open”.

I hope this article will be helpful to have more understanding of the circuit breaker design pattern and you can apply to your work. To help solve some problems, more or less. I apologize if there are any mistakes.

References

Circuit breaker design pattern - Wikipedia

Circuit Breaker Pattern - DZone Microservices

Circuit Breaker