What is purging?
Last updated 2022-05-02
Once you have figured out how to cache your content, efficiently invalidating it is another matter. As Phil Karlton aptly described, “There are only two hard things in computer science: cache invalidation and naming things.” Cache invalidation, otherwise known as purging or cache purge, is the process of eliminating content objects from cache ahead of when it would naturally expire or be evicted. Once an object is purged, a request for that object will be retrieved from the source rather than the cache.
There are many reasons why you, as a website owner, might want to purge cache. For example, suppose you are an online retailer. You want to make sure the price or quantity of a product is always up to date. This might be a reason to implement a purging policy. Or, let’s say you have a news website and the headline or content of an article is no longer valid. You want to purge so that the new title and content will be retrieved from your origin server and stored in cache.
In our What is caching? guide, we learned that HTTP headers transmit information about requests and responses, including how long to keep the requested object in cache. While an object is stored in cache, it has a freshness lifetime, also known as a TTL or time to live, and can be served without needing to be revalidated by the origin server. Once the cached object reaches its TTL value, it expires and the cache is no longer considered fresh. This object may continue to be served stale before it’s formally evicted and the cache revalidated.
Purging invalidates an object ahead of when it would naturally expire. You may want to purge something because it’s incorrect, out of date, or because you have a breaking update. Whatever the case, you are purging to replace what's currently cached on your site with newer, fresh version on your origin.
Let’s consider one of the examples we gave earlier. Let’s say you publish a news article but notice there’s a mistake. You correct the article and push it to your origin servers using your deploy process. However, the incorrect article still remains in cache and can be served to customers until you send a purge request, which you can also do with an HTTP header. Purging informs the cache to stop serving the cached object to client requests and instead retrieve the newer object from origin. This newer object replaces what's in cache and can be served in response to subsequent requests.
Note that this method of purging only works for remote caches you have implemented, like a reverse proxy or CDN. You cannot send purge requests to a user’s local cache, like their computer browser, to force it to purge. If you’re using a CDN, we recommend setting HTTP headers to prevent objects from being cached in the browser in the first place.
When purging objects, you want to make sure you’re purging the right amount of cache at the right time. Purging your entire cache when only a few files are stale is inefficient and expensive to revalidate. With Fastly, you can precisely purge only the objects you want updated. Each of our different purging methods can be initiated via the Fastly web interface or API and are executed on a single service (not across multiple services).
Fastly also gives you the option to execute certain purges as a soft purge or a hard purge. A soft purge invalidates an object and marks it as stale. The next time a user requests the object, they’ll be served the stale object and then the updated object will be retrieved from origin. Stale objects can also be served to client requests even when your origin servers are down. A hard purge permanently invalidates cached objects and makes them unusable for future requests. It forces Fastly to retrieve that object again from your origin servers before it can be re-cached in Fastly POPs.
For the rare situations when you want to purge your entire cache, initiate the Purge all option. By design, Purge all is a hard purge because it invalidates the entire cache in one action.
For more targeted purging, Fastly lets you purge by URL or surrogate key. Purging via URL or by surrogate key is gentler on your origin because it lets you invalidate one object or a targeted set of objects instead of the entire cache. This also saves you money because you’re only purging what you need to. When you purge via URL, you specify a single URL path to purge. When you purge by surrogate key, you assign a unique identifier to a set of objects and specify to only purge objects with that identifier. This is helpful for purging groups of related objects. Additionally, both of these options can be run as soft or hard purges.
Purging with Fastly has benefits for both you and your end users.
The global average time it takes Fastly to purge your content is 150 milliseconds (it's frequently faster!). This lets you cache objects for longer and purge on demand when needed. Plus, you can use an API client or integration to automate the purging process to instantly purge whenever your content changes, giving your users access to the latest and greatest version.
Fastly servers have a distributed purging system, which means our cache servers are responsible for distributing purges themselves. This means you can send a purge to the nearest server, and from there it’s sent directly to all other cache servers, removing the single point of failure that comes with a centralized system. If there's an outage in a certain area, other cache servers can respond to purge requests.
By caching at the edge and purging in real-time, you can serve more requests from the cache and minimize trips to origin, which reduces the load on your servers. This means you can spend less on servers and other related infrastructure equipment and instead rely on Fastly to store and deliver content.
You can access Fastly’s purging features by using the Fastly web interface or the Fastly API. Our Introduction to Fastly's CDN tutorial has real-life examples for purging your entire cache and purging with keys.