Circuit breakers are a design pattern that allows an application to avoid catastrophic failure in the event that a dependency is unavailable. A circuit breaker protects a specific piece of functionality by detecting a failure from an external source such as a REST API. Rather than allowing your application to crash, the experience can be changed.
Once a failure is detected, the circuit breaker trips -- similar to how circuit breakers in your home protect your appliances from catastrophic failures during power surges or short circuits. With multiple parts of your application utilizing different circuit breakers, that one part can be changed or disabled in the event of external failure, rather than having your entire application be affected.
Some examples of why a circuit breaker could trip when calling an external API are:
These failures can even have some built-in tolerance, where they can be retried or can count the number of failures before tripping.
The first thing that will happen is that your application will change. While we'll cover a real-world scenario later, this change could show in a number of different ways. For example, a non-essential component on your page could be hidden, or a backup system could be used.
In its normal state, a circuit breaker is closed. This allows the part of the application protected by the circuit breaker to operate normally.
When enough failures occur for that part of the application to be considered inoperable, the circuit breaker will open and will serve the changed state.
After a predetermined amount of time (or other condition), the circuit breaker will become "half-open". In this state, you could start reaching out to your failed external API and monitoring the responses. After a determined threshold is reached of successful responses, the circuit breaker will close and go back to normal operation for all users.
As the software world becomes more complex, many organizations are moving towards building scalable applications while maintaining a level of budget-consciousness. With cloud computing and infrastructure automation becoming more ubiquitous each year, we are building (and seeing others build) applications that scale by utilizing a microservices architecture rather than scaling large monoliths. Depending on your architecture, this can create a potential network-related point of failure for each service. This also contributes to a rise in frontend JavaScript applications that focus on components.
This is an important and sometimes overlooked part of application development as many organizations only pay attention to the benefits of backend efficiencies. By focusing on building components, we can use circuit breakers to their fullest. With circuit breakers implemented on the backend, a frontend framework such as React, Angular, or Vue is the perfect pairing. In these environments, components are much more dynamic and feature-rich, with the ability to change on-the-fly.
By combining a robust backend with circuit breakers along with a componentized frontend, users can go about their day-to-day without the application being completely affected by an outage of a backend service.
To keep this simple, let's imagine a home-grown intranet at a small business. When users login, they see all the things you'd expect -- the welcome message, some downloadable documents, pages to manage their preferences, and maybe a weather component. This is an example that has been explored by numerous books, blogs, and git repos, being that weather services have been around forever and are just a nice go-to.
This weather widget has a few components to it:
Normally, you would login and see the nice sun icon with a perfect 72 degrees underneath, and then the next few days, but not today. Today, the weather API that your company uses is having a major network outage and can't serve up responses.
Not to worry! The circuit breaker on your backend has flipped open, the page, being a clean single-page app, loads quickly, and the weather component shows a nice image of a cloudy sky with a message saying "Service Unavailable".
This is one simple real-world example but imagine the possibilities. You could switch between shipping carriers, or to a backup payment provider. You could even switch to another third-party weather API that you normally don't use because it's not as accurate -- and your users wouldn't be negatively impacted.
Photo by Michael Dziedzic on Unsplash
If you’d like to learn more about SUMO Heavy, drop us a line, give us a call or contact us on social media.
