Why APIs Are Still a Top Cause Of Downtime: 3 Ways to Protect Your Site

We live in a world where all of our gadgets are increasingly becoming interconnected in all sorts of convenient ways. While this is generally a great thing, it's important to think about the risks that all of these interconnections can create. When it comes to managing a site, if you call an external API and that API provider is having a bad day, that can easily degrade the quality of your service. End users could experience critically slowed performance. At worst, your site could be totally unavailable to customers.

I've seen this crop up a lot in my time at Pantheon — one of the biggest causes of poor site performance and even site downtime is actually that someone else's website or API is degraded. The problem is that computers are super literal, and most of the time programming assumes "blocking" I/O - meaning that the software stops and waits when it asks for data from some other source like a disk or network resource (e.g. a RESTful JSON API endpoint). That means that when you integrate an API, if you're not careful you're tying your uptime and performance to whoever is managing that external API, up to and including the quality of their network connection. It's the domino effect of API dependencies. When one falls, it can knock others offline.

Luckily, it doesn't have to be this way. The following are three best practices for API integrations that can save you from getting hit with this kind of pain.

Measure external API Performance

It's cliche but it's true: if you can't measure it, you can't manage it. You should always know how external API calls are performing so you can be aware of common problems and error rates. There are numerous and easy tools for doing this, both on the frontend and backend. Despite that, many overlook the value of those tools. Even if you're implementing something from a super-stable provider (e.g. Google or Facebook), you should still understand the performance implications, and have the telemetry to understand quickly what's going on if they do ever have an outage (or more likely just deprecate the version of the API you're calling).

Establish Boundaries With Timeouts

The single most important thing to do when implementing an API on a backend is to set the maximum time you're willing to wait for a response, what's known as a timeout. Because most software blocks for I/O, and also most code defaults to "forever" as the timeout, a naive implementation leaves your site or application at the mercy of every external API provider. On an average day, it doesn't seem like a big deal. One slow API call can cause a less good experience for one user, and you could decide that that's ok. However, a bunch of them can quickly tie up all your resources waiting for API responses, meaning there's no capacity to serve new visitors. You're better off "failing fast" and delivering an error after waiting a few seconds vs "failing forever," meaning you're effectively off the air.

Explore the Async Option

Another good approach is to get rid of the "blocking" part of how your code handles I/O, which can significantly reduce the impact of a slow or unavailable external API call.

This is generally straightforward on the front end where Javascript makes it easy (though you should still set a timeout). But you can do it on the backend too. Depending on your use-case, you may be able to leverage libraries or frameworks to make this easier. The easiest case is where there's something that's really not required to deliver the main response, like a call out for analytics or logging. In PHP you can use shutdown functions for this, or spawn a subprocess to handle the work.

Managing external APIs doesn't have to be a pain if you go with the right approach from the outset. Protect your website from these common crash points by being proactive about how APIs are integrated into your system. That way, if a kink in the system occurs, your website won't be the one to deal with the fallout.

Be sure to read the next API Management article: Arboric Debuts as an API Manager Dedicated to GraphQL

 

Comments (0)