What Is CDN Cache Invalidation

BeoHosting Team·17. jun 2025.·11 min read read

Introduction to CDN caching

Content Delivery Network (CDN) works by caching copies of your content on edge servers worldwide and serving them to users from the nearest server instead of every request going to your origin server. This dramatically reduces latency and speeds up site loading for users regardless of where they're located. However, caching brings a fundamental challenge - how to ensure users always see the latest content version when you make changes on the site.

Cache invalidation is the process of removing or replacing outdated content from the CDN cache. Phil Karlton once said there are only two hard things in computer science: naming things and cache invalidation. This statement perfectly illustrates how complex cache management is because every wrong decision can result in users seeing outdated content or the origin server being unnecessarily burdened because the cache is too aggressively cleared.

How CDN cache works

When a user first requests a resource not in cache, the CDN forwards the request to the origin server, gets the response, and stores a copy on its edge server. Every subsequent request for the same resource from the same edge server is served directly from cache without contacting the origin. The origin server controls cache behavior via HTTP headers like Cache-Control, Expires, ETag, and Last-Modified.

Key HTTP headers for caching

Cache-Control: max-age=3600 - resource is fresh for the next 3600 seconds (1 hour)
Cache-Control: s-maxage=86400 - specific for shared caches (CDN), priority over max-age
Cache-Control: no-cache - cache must revalidate with origin before serving
Cache-Control: no-store - resource must never be cached
ETag - unique identifier of resource version for revalidation
Vary - determines by which headers cached versions differ

Understanding these headers is key because they define the rules by which the CDN decides whether to serve the cached version or request a new one from the origin server. Improperly configured headers are the most common cause of issues with outdated content or unnecessarily frequent requests to origin.

Cache purging - manual cache clearing

Cache purging is the most direct way to remove content from CDN cache. Most CDN providers offer API and dashboard for manually triggering purge operations. You can clear a single URL, group of URLs by pattern (wildcard purge), or complete cache of all resources. Each approach has advantages and disadvantages depending on the situation.

Types of purge operations

Single URL purge is the most precise and fastest method because it targets exactly one resource. Use it when updating one page or file. Wildcard purge deletes all resources matching a certain pattern, for example /blog/* deletes all blog pages from cache. This is useful when updating a larger number of pages but you don't want to clear the complete cache. Full purge deletes absolutely everything from cache and should only be used in urgent situations because it temporarily increases origin server load while cache is rebuilt.

Purge operations usually propagate through the CDN network in 1 to 30 seconds depending on provider and network size. Cloudflare network purge propagates in about 30 seconds globally, while AWS CloudFront may require up to 15 minutes for wildcard invalidations. Always keep this delay in mind when making production changes and testing whether the new version is visible.

TTL strategies

Time-To-Live (TTL) determines how long the CDN considers cached content fresh before requesting a new version from origin. Properly setting TTL is a balance between performance (longer TTL = fewer requests to origin) and content freshness (shorter TTL = changes seen faster). There's no universally correct TTL because it depends on content type and how often it changes.

Resource versioning

Resource versioning is the most elegant strategy for solving the cache invalidation problem because it completely eliminates the need for explicit purge operations. Instead of changing file content at the same URL, each new version gets a new URL meaning the CDN automatically serves the new version because it treats it as a completely new resource not yet in cache.

Versioning methods

Content hash in filename is the most popular method. Build tools like Webpack, Vite, and Next.js automatically add content hash to filename, for example style.a1b2c3d4.css. When the CSS changes, the hash changes and a new file with new name is generated. The old version stays in cache but no one references it anymore because HTML now points to the new file.

Query string versioning (style.css?v=1.2.3) is a simpler approach but less reliable because some CDN providers ignore query strings when caching. Use it only if you can't change the filename. Path versioning (/v2/style.css) is another option that works reliably with all CDN providers but requires more configuration on the server.

When to invalidate cache

Knowing when to invalidate cache is just as important as knowing how to do it. The most common scenarios requiring invalidation include deploying a new site version on the hosting server, correcting a critical error in content, removing sensitive content accidentally published, and changing prices or product availability in an e-commerce store. In all these cases, users must see updated content as soon as possible.

Invalidation best practices

Automate - integrate cache purge into the CI/CD pipeline for automatic invalidation on every deploy
Be precise - target specific URLs instead of full purge whenever possible
Use versioning - for static assets completely eliminates need for manual invalidation
Monitor - track cache hit ratio to discover configuration problems
Test - check headers with curl -I to confirm caching works as expected
Document - record TTL values and invalidation strategy for each content type

Common problems and solutions

One of the most common problems is the so-called stale content where users see outdated content despite changes you've made on the origin server. The cause is usually too long a TTL without an invalidation mechanism. The solution is the combination of a reasonable TTL with automated purge operations on deploy. Another common problem is cache stampede where after TTL expires for a popular resource, hundreds of concurrent requests simultaneously hit the origin server. The solution is request coalescing where the CDN sends only one request to origin while holding all other requests until receiving the response.

The problem of different content versions on different edge servers (cache inconsistency) arises because a purge operation can't propagate to all servers simultaneously. During the short period after purge, some users will see the old and some the new version. For critical changes, use the URL versioning mechanism that guarantees consistency because each user accesses an exactly defined resource version.