Akamai Diversity
Home > CDN > How your caching strategy will evolve with Fast Purge?

How your caching strategy will evolve with Fast Purge?

After having fine tuned every knob, switch, and slider to maximize cacheability on the Akamai Network, you head over to look at the offload graph hovering at a hair under 100 percent, taking immense pride in what you've accomplished. All in a day's work! The next morning rolls around and you come to find out that the Marketing team is launching a promotion to increase customer engagement and sales that requires a major update to the homepage... the kind of launch that requires removing objects from cache and re-publishing new ones, all within the instance it takes to split an atom into its elements.

And just like that, your sense of accomplishment starts to dwindle and you now find yourself scrambling to find a fix that won't take all night to execute. So how do you go about handling this common scenario?

First, let's look at the different ways you can purge content today on the Akamai Platform:

Content Control Utility (CCU)

CCU is the most widely used purge mechanism Akamai currently offers. It takes complete URLs as input protocol through query string and completes the purge in approximately four minutes, or a bit longer depending on how many URLs were submitted. You can access CCU via Luna or the REST based {OPEN} API. CCU provides options to delete (remove) or invalidate (expire TTL to mark object as stale), which leads the edge server to refresh the content with an If-Modified-Since request, reducing bandwidth load on the origin in case of no content update. If the upstream server sends a Last-Modified-Timestamp (LMT) header in the response, an If-Modified-Since request will cause edge servers to conditionally request content based on the Last modified timestamp of the resource. Otherwise, the request defaults to a full GET.

Note that in most cases, invalidation suffices and meets the same end goal, while providing better origin offload and enabling Akamai to serve stale content in case the origin is down. Deletes are performed in case of legal requirements to remove physical content or if the LMT is not updated chronologically. CCU also allows you to purge by CPCodes so that all content associated with a certain CPCode is deleted or invalidated. Fair warning: use this option with extreme caution. It's not for nothing I call it the nuclear option!

Enhanced Content Control Utility (ECCU)

ECCU is the heavy-weight lifting backstop for purge on the Akamai Network. It has the ability to invalidate content via an extremely elaborate list of matches, and do so consistently in about 30 minutes. ECCU only invalidates and does not provide the option to delete content. In most cases this is not an issue, except when the content update did not change the LMT of the object. You're able to refresh content in many different ways, including by path match or file extension, a specific query string argument, the presence of a response header value, or a combination of all of the above. The power that ECCU provides in the hands of the admin is immense. It has the potential to surgically refresh specific parts of a library or the complete cache repository for multiple domains. ECCU can be managed via the Luna Control Center or the SOAP API.

Fast Purge

Fast Purge (currently in beta) is the latest iteration of the purge infrastructure and is designed to replace CCU completely in due course, while providing 100 percent feature parity. By now you must be wondering: so why go with the new "Fast Purge" and how fast is it really? Fast Purge improves on CCU by letting you purge content across the network in under five seconds. So all submissions, virtually any number of objects being purged, now complete across the network in under five seconds!

What this means is that you can submit and complete the purge in less time than it takes your webpage to refresh in the browser or the CCU API to respond with the submission status. There is no queueing involved, no waiting for purges in the front to clear out before the latest submission refreshes content on the network. You can correct content published in error and see updates to your web properties instantaneously. With Fast Purge, you can now evolve your caching strategy from TTL-based caching to hold 'til told. With hold 'til told, you can improve origin offload and page load time performance by caching all of your content with long TTLs, avoiding frequent refresh requests at the Edge.

Now that you know about the various methods available to purge content, let's talk about the scenarios which may arise (like the last minute Marketing campaign) and require you to leverage one versus the other. Purges get triggered due to a number of reasons and typically fall into the following three buckets:

Ad-hoc object purges:

These purges are ones that aren't predictable, they come in due to changes in system, inventory, or dynamic offers. Most of the components of the page remain the same except for an update to the images, for example. The URLs remain the same, the content refreshes, there isn't ambiguity in the content to be purged e.g. whether the HTML was updated or the embedded JPG/PNGs. This is a perfect scenario for using CCU to refresh content for the specific resources that have changed. In the very near future (or even today if you sign up for the beta), it would mean using Fast Purge instead of CCU to achieve the same end result, within seconds.

Planned content updates:

There are situations where a major revamp of the property is due, e.g. publishing a sale or the launch of a completely new product line leading to significant content updates. If the specific URL updates are known, then CCU would definitely help. If the number of URLs to be purged is significant and can be pattern matched, ECCU is the best bet for a content refresh. ECCU will also let you leverage scheduled purges for a time specific content update. 

Because you've read this far, I will reward you with a sneak preview. Fast Purge will introduce "content tagging" in 2016. Content tagging will let you logically group different pieces of content together under a single textual tag, and then purge that tag with one simple command within seconds, instead of the 30-minute propagation time of ECCU. This makes it the best of both the CCU and ECCU worlds.

Emergency cache drops:

This is a scenario we all dread and hope never happens. For example, your CMS had a small hiccup leading to incorrect content being published, and there is no identifying pattern to isolate good vs. bad content. The primary goal here is isolating the bad content that got published and updating it so that it's correct. Once you've identified the impacted content and the CMS has been updated to publish the correct content, you'll want to begin your purge. As in the scenario above, Fast Purge, CCU or ECCU can be leveraged depending on the distribution of URLs that are affected and how they can be grouped.


The goal of this post is to shed light on some of the different ways you can manage content on the Akamai Network, better and more efficiently, without causing unplanned load on your origin. Please don't hesitate to comment on the post directly or ask questions specific to your scenario. If you're interested in signing up for the Fast Purge beta, your Akamai account team is here to help or simply reply to this Community discussion post and we'll be in touch!


Does Fast Purge support patterns/globs (like */folder/* or *.js or compound ones like */folder/*/*.js) or does Fast Purge only exact-match URLs?

And if not, can you at least purge an exact URL plus all query string variants of that URL without having to know/specify the potentially unknowable list?

Thanks in advance!

Fast purge currently requires exact match URLs the same as Content Control Utility so wildcards will not work with Fast Purge.

The Content Tagging feature for Fast Purge will be available in early 2017 to support functionality along these lines.

To be able to purge all possible variations of query string using the base URL, flex cache id or Dynamic Page Caching needs to be enabled on the edge configuration. This generates cache keys which are variants of the base URL allowing you to purge the base URL to remove all possible combinations. Your Akamai representative should be able to help you set this up.

Leave a comment