Circuit Breaker Policy for API Gateway

In June, Axway hosted our first ever API Management customer-facing hackathon in Northern Virginia. It was a great event that enabled some of our best and brightest to collaborate and co-create with our customers who brought their use cases to the table. We worked together in order to rapidly prototype solutions with real-world applications to address today’s challenges. The end results were practical artifacts for immediate use, built to perform with insight from our solution leaders, and built to maximize usability with input from our customers. These results were then made available for free in our Git repos and on the Axway Marketplace. The first artifact we created was a Circuit Breaker policy for the Axway API Gateway.

What is a circuit breaker?

In development, a circuit breaker is a design pattern to circumvent reoccurring failures by changing the flow when a process, repository, external system, or any external dependency is failing. Rather than continuously attempting to utilize the failing resource, the circuit breaker will implement a logic change or fail over to a fault handler rather than continuing down the same path until the issue is resolved or for a set period of time. This can also be used for things like a planned maintenance outage.

Do you need a circuit breaker?

Circuit breaking is imperative for enterprise grade systems. You don’t want to continue to waste resources trying to call something that is not responding. You may have all the security in the world on the front end, but an unresponsive backend taking 30 seconds to timeout in a high transaction environment can cause a denial of service as surely as any attack. This can interrupt internal app to app processing, security meditation, and other workflows. Worst of all though, even if it’s just causing a temporary slowdown, it can ruin a customer experience, leading to lost opportunities and revenue. Circuit breaking can help resolve this issue, especially if used in conjunction with our new AMPLIFY Streams offering. By enabling streaming APIs in place of request-response APIs, you can provide much more rapid results in real time, and vastly limit the calls inbound to your services and resources.

Circuit Breaker Policy for API Gateway

Our new Circuit Breaker policy on the Axway Marketplace. Check it out HERE.

It is a sample policy framework of how one might implement this within the Axway API Gateway using only OOTB filters with a minimal amount of extended logic built into the Scripting Filter.

Circuit Breaker Policy for API Gateway

And, if you haven’t already, it’s also worth a look at our new AMPLIFY Streams solution.

Finally, do you have some ideas or challenges for API Gateway policies for our next hackathon in September in Paris? Head over to the Axway Community site and add them to the discussion. Your idea might be the next item we create and add to our Axway Marketplace to help our customers AMPLIFY their Application Integration.

Previous articleAn example of microservice architecture implementation
Next articleAutomotive landscape: How APIs and hybrid integration drive business


Please enter your comment!
Please enter your name here