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 articleThis Week’s Modules & Widgets: June 28, 2019
Next articleTalk with a Titan: Adam Armstrong
Daniel Wille is an Axway AMPLIFY Platform architect focused on helping our clients accelerate their digital transformation journey. Daniel is a long time member of the Solution Architecture team and brings a unique perspective having implemented solutions from every major product line and several minor ones as well, and having managed the Axway US Federal technical team for nearly half a decade, with a focus on enterprise security, governance, and observability on large and complex “can’t fail” mission-critical systems. He is passionate about extending customer relationships beyond the current project with a longer term goal of becoming a trusted adviser, and exploring continued efforts to bring greater value to businesses and agencies via digital disruption.