True cutting edge CDNs (Content Delivery Networks) offer features that differentiate them and allow you to cut costs in innovative ways while at the same time improving performance. (They also do a lot to secure your site, but that is for another post.) One of the differences that Fastly offers is the ability to invalidate content (think PURGE or DELETE) in milliseconds. Hooman Beheshti has a great article about a different kind of content than Static or Dynamic.

That content is Event Driven content – content that isn’t static, and isn’t truly dynamic. You know it is going to change but don’t know when. Good examples include inventory, arrival times, sporting scores and comments on blogs or products. And if you are able to cache this content until it does change (and then quickly invalidate it from the CDN) you can not only reduce load on your servers but also provide extremely fast performance. I wouldn’t be surprise if you were actually able to take systems offline and reduce costs even more.

One of the use cases that I always found exciting was for Hotel Tonight. Because of Fastly they are serving hotel searches (the most expensive to serve from a compute standpoint) from cache in under 50ms. This has reduced the traffic hitting their servers by as much as 80%. So we are talking faster performance and most likely reducing data center needs.

A use case like this should have many firms thinking about caching API calls. Those are often Event Driven content, so the data can be cached until it changes – then flushed from cache fast enough that new content can replace it when requested again. The challenge that can be intimidating is knowing which API calls to cache and which to pass through. Then there is also thinking about which preexisting cached data the PASSED data made no longer correct to be cached. The easiest way is to take an acronym (for persistent storage) of CRUD and apply the same logic to your API classifications.

With CRUD, the functions are broken up as being either Create, Read, Update or Delete. When you view your API calls as though they were related to how data is handled in this model you can quickly decide what can be cached and what should be PASSED through to the origin to be acted on. At a high level, think of them like the following:

• Create – in this instance you are adding data. In the Hotel Tonight example it might be one of their 10,000+ hotel partners adding availability, or any of the users (11 million app downloads!) creating a reservation. (Just a theory that the partners leverage a system that might cache data or that Hotel Tonight is caching APIs. More interested in tangible example ideas here.) Basically if you are adding data then that call can’t be cached and has to be PASSED. But any data that changed and could be later requested by a Read (see below) needs to be purged.
• Read – where you are asking for data. This is a mixed call in terms of complexity. In general it is something you just cache as often as possible. But you’ll want to look at something like surrogate keys or some other logic to track what to purge when a Create, Update or Delete changes the cached Read data. (It the needs to be purged so the next request gets the new data rather than the old cached data.)
• Update – very similar in concept to Create. You are Updating data, so the request needs to be passed to the servers. You also need to keep in mind that any data that would normally be Read that would now change needs to be PURGED. Again, surrogate keys are a blessing here.
• Delete – also the same concept at Create or Update from a caching API perspective. If you are deleting something (like a reservation) the web request has to be PASSED through to the origin. And if (for example) you just freed up inventory by deleting a reservation this is a great example of event driven content. The rooms available for that hotel just increased. So just like Creates and Updates you need to purge any data that could be later Read that would change because of this Delete. Again, surrogate keys give you tremendous power to organize what data to purge that a specific Delete would modify.

Now these example API calls are purely made up in the Hotel Tonight example. I wasn’t involved with that POC or implementation but wanted to give some examples that might be easier to comprehend. With Fastly you can cache content that you wouldn’t with other CDNs because others don’t make it possible to invalidate (purge/delete) fast enough. And with surrogate keys you have tremendous power to organize content and delete a large number of grouped possible Read calls with one Purge request. Anyone familiar with REST will also see how the CRUD analogy can be applied to decide what can be cached as well as what to be grouped for purging or invalidation. But I’ll leave that for another possible post some day!