How to Set Up APIs to Avoid Website Performance Disasters

This article was prepared by a guest contributor to ProgrammableWeb. The opinions expressed in this article are the author's own and do not necessarily reflect the view of ProgrammableWeb or its editorial staff.

As more retail websites adopt a global outlook, the Western holiday season will not be the only time marketing teams look to flash sales to boost sales. In order to make these events worth the cross departmental effort they require, web teams need to make sure their websites are set up properly to handle the added strain from extra web traffic or they will risk upsetting their customers who cannot complete a purchase due to a slow or non responding website. eCommerce web teams can use the new year as a chance to re-examine the elements on their websites to prepare as the next flash sale is around the corner.

APIs play an increasing role in generating the dynamic web content that makes the modern web exciting as more websites are moving to Single Page Apps and are relying on API frameworks for critical operations such as improving the shopping cart functionality. Although it’s not a shopping app, the Gmail web app (not the mobile version) is a great example of an SPA. Once you sign into Gmail.com, all interactions happen within the context of a single web page.

But in times of beyond-peak traffic volume, API calls can be the factor that breaks a website. Savvy web teams will itemize the functionality of their websites and evaluate their priorities for what they need. Web teams should follow three tips to deploy their APIs and avoid website disasters for the remainder of this holiday season and on throughout the next year.

Embrace Cache-only Transactions

“The fastest HTTP request is the one not made” is an adage made famous by web performance expert Steve Souders. This continues to be as true for APIs as it is for any type of web content. While dynamic APIs on web pages improve the user experience, the extra resources required to make them work can have the opposite effect during traffic spikes.

Web teams should examine which pieces are static and where it is possible to trim total API calls. For example, what if you strip down your site to only check for inventory and perform database queries when a user is adding items to the cart? Assuming an outstanding conversion rate of 10 percent, that can mean website infrastructure only needs to handle around 10 percent as many requests as it did before, while the rest is cached.

This design enables website infrastructure to focus on dynamic, mostly revenue-oriented tasks rather than dedicating limited resources on unchanging and immutable requests that can be served from a cache server. It’s a concept that Single Page Apps (SPA) have taken to the extreme. On a SPA, there is only one HTML page that works as a wrapper and every interaction with the server is an API call. It’s a powerful performance tool as long as web teams remember that API calls can be cached as well.

Web teams should cache “products API” calls in the same way that they cache product pages, which means retaining separation of concerns on API calls to keep static and dynamic content on different HTTP operations. This approach to caching everything may seem like a drastic step, but it allows websites to scale in a more reliable, linear and budget-conscious way to meet fluctuating demand.

Keep the end goal in mind

Reducing functionality does not mean eliminating functionality. There are some functions that are essential to the main goal of the business; in the case of online retail, this means anything related to converting site visits into sales.

When it comes time to tightening belts in preparation for high-traffic seasons, organizations tend to focus on pages that receive more traffic (hits). At the end of the day, these are the entry points to the site; however, these entry points are either static, and thus cacheable for at least a short period, or heavily optimized for delivery, as they have been the subjects of multiple optimization projects.

Instead, web teams need to first identify the effect each API or other dynamic site function has on user behavior and preserve the ones that drive conversion without hoarding resources. What should you do with the other functionality?

If it does not drive revenue, turn it off temporarily.

If it does but consumes many resources, consider skinnying down to alternatives that are less resource intensive.

For example, searching is one such site function that is both resource intensive but also critical for generating sales. Site visitors can’t buy products they can’t find, but constant calls to search the entire product database can create a lot of pull on the site, especially if the search function uses an external API that cannot be cached by you.

Flip the switch

The conflict between high performance and high functionality is a struggle that will last throughout the information age. But reducing websites to their “minimum viable product” can keep a website afloat in the face of any traffic spike.

During high-traffic spikes, web teams can swap out APIs and web components with excellent functionality for ones that are good enough. The key to making this strategy work is to find and to develop an easy way to toggle between the two modes.

In the case of search functionality, customer searches often follow an 80/20 rule, in which 80 percent of searches will be for 20 percent of the products (popular items). This makes it possible to use web server logs to identify the most popular searches and create redirect policies that take users to product families or brand pages rather than precise results.

Once web teams have policies like that in place for popular searches that bog down web performance during beyond-peak, it’s easy enough to set up a dashboard with toggles for web teams to switch between rich and powerful searches and redirects when needed.

It often seems like the web team’s primary job is to keep pushing a website to the cutting edge of functionality. The reality is the job of the web team, both developers and operations, is to make the website best able to support the business goals of the organization it serves. Sometimes that means dialing back the functionality in order stay online. The best web teams are those that understand their business’ goals and find ways to make the website meet them. As online retailers move from predictable yearly cycles we see during the holiday season to a more global view of their customer base, the ability to adapt to changing website loads is crucial for success. But web teams at every organization can take lessons from their success as they figure out better ways to deploy their APIs.

Manuel Alvarez
Manuel Alvarez is an enterprise architect and multi-lingual CDN and Cloud evangelist. In his current role at Akamai, he drives innovation by researching and implementing novelty solutions and technologies, sharing best practices in blogs and conferences, identifying and closing customer gaps, and designing complex architectures.
Having previously owned his own software development company, providing consulting to financial, telecommunication, and high-tech companies on business process optimization and information systems, Manuel excels at providing a mixture of technological and business insights to his clients.