Milliseconds matter

Considering the performance factor in an API-driven world

Per Buer
Speed image via Shutterstock

With visitors demanding immediate response times, the fate of a website and the performance of APIs are becoming increasingly intertwined.

In recent years, web APIs have exploded. Various tech industry watchers now see them as providing the impetus for a whole “API economy.” As a result and in order to create a fast track for business growth, more and more companies and organizations are opening up their platforms to third parties. While this can create a lot of opportunities, it can also have huge consequences and pose risks. These risks don’t have to be unforeseen, however.

Companies’ checklists for building or selecting API management tools can be very long. Most include the need to offer security (both communication security -TLS- and actual API security -keys-), auditing, logging, monitoring, throttling, metering and caching. However, many overlook one critical factor: performance. This is where you can hedge your bets and plan for the potential risk.

per buerThere’s an interesting analogy between APIs and the long path websites have travelled since the nineties. Back then, websites had few objects and not that many visitors so performance and scalability mattered less. This has changed dramatically over the last decade. Today, increasingly impatient visitors penalise slow websites by leaving quickly, in and many cases never returning. Microsoft computer scientist Harry Shum says that sites that open just 250 milliseconds faster than competing sites – a fraction of an eye blink – will gain an advantage.

APIs have travelled a similar path. Ten to 15 years ago most API management tools out there had very little to do and performance wasn’t an issue. The number of API calls handled was often measured in calls per hour. Consequently, these tools were designed to deal with other things than thousands of API calls per second. What a difference a decade can make! According to Statista, worldwide mobile app downloads are expected to reach 268.69 billion by 2017. But API management tools haven’t caught up. Even nowadays many of the products in the various vendors top right quadrant will only handle rates of 200 API calls per second per server. Their focus has been on features, not performance.

SEE ALSO: API designers, be careful

If you open up your API platform, you probably want a lot of developers to use it. However, most web services have introduced a rate limit for API calls. If set high enough, the limit is reasonable to ensure availability and quality of service. But what is high enough to provide a competitive advantage in our accelerated times? Take for example an industry like banking, where many players are opening up their platforms in a competitive bid to attract developers who create third-party apps and help monetise the data. The ones that set the API call limit too low create a bad developer experience, pushing them towards friendlier environments.

jax londonA limited number of API calls in web services also affects the end-customer. Take for example online travel operators or online media. In these environments a lot of data needs to flow through the APIs. These are becoming more dependent on fast and smooth communication between their services and their various apps. If these services slow down due to API call limitations, customers will defect to faster sites.

I compared the situation of APIs with that of the web ten years ago when performance started to matter. The situation that actually developed is much more serious than I initially predicted. Consumers increasingly demand instant gratification. This means that the window for companies to ensure the performance of their APIs is closing. Being able to deliver performance and set a higher limit of API calls can make a huge difference. Otherwise, developers will go elsewhere to help grow another company’s business. If you want to future-proof for the API boom, it’s time to consider the performance factor.


Per Buer

Per Buer is the CTO and founder of Varnish Software, the company behind the open source project Varnish Cache. Buer is a former programmer turned sysadmin, then manager turned entrepreneur. He runs, cross country skis and tries to keep his two boys from tearing down the house.

Inline Feedbacks
View all comments