Cache Invalidation

An immediate, hard removal of an object from the cache before its natural TTL expires. This is triggered by an event-driven workflow in the CMS, such as a publish or update action.

• Soft Purge: Marks content as stale but serves old version while re-fetching.
• Hard Purge: Deletes the object immediately, causing a cache miss.
• Surrogate Keys: Tags that allow purging entire groups of related content with a single API call.

The foundational infrastructure that makes invalidation necessary. Edge caching stores content copies on geographically distributed CDN servers to serve user requests from the nearest point of presence, drastically reducing latency. When origin content changes, these distributed copies must be purged or updated. Without robust invalidation, edge caches serve stale data. Modern CDNs offer instant purge capabilities that propagate globally in under 150 milliseconds, but the challenge scales with the number of edge nodes—major providers operate 300+ points of presence worldwide.

The primary passive invalidation mechanism. TTL is a directive specifying how long a cached object remains valid before the cache must revalidate with the origin server. Common strategies include:

• Short TTLs (1-60 seconds) for real-time data like stock prices
• Long TTLs (7-30 days) for static assets with versioned filenames
• Adaptive TTLs that shorten as content ages TTL-based expiration is eventually consistent—stale content may serve until the timer expires, making it unsuitable for urgent corrections or breaking news.

A tagging system that enables targeted invalidation of related cached objects with a single purge command. Instead of purging individual URLs, you assign tags like post-1234 or author-jane to cached responses. When a piece of content updates, you send a purge for its tag, and every cached object carrying that tag is invalidated simultaneously. This is essential for:

• Content federation: updating a product description across all listing pages
• GraphQL responses: purging all queries containing a mutated entity
• Personalized content: clearing user-specific caches on profile changes

A cache directive that balances freshness with performance. When a cached object expires, stale-while-revalidate instructs the cache to serve the stale version immediately while asynchronously fetching the updated version in the background. The next request receives the fresh copy. This eliminates the thundering herd problem where multiple simultaneous requests trigger redundant origin fetches. The directive Cache-Control: max-age=60, stale-while-revalidate=3600 means serve fresh for 60 seconds, then serve stale for up to an hour while revalidating.

A security vulnerability where an attacker causes a cache to store a malicious or incorrect version of a resource, which is then served to other users. This exploits flaws in cache key normalization—how the cache determines what constitutes a unique object. Common attack vectors include:

• Unkeyed headers: injecting payloads via X-Forwarded-Host that the cache ignores but the application processes
• Fat GET requests: caching responses to requests with a body, which HTTP semantics forbid
• Parameter cloaking: exploiting discrepancies between how the cache and origin parse query strings Invalidation is the primary remediation—purging poisoned entries immediately upon detection.

An HTTP mechanism for validation-based invalidation rather than full re-fetching. The cache sends a conditional request to the origin with headers like If-None-Match (containing an ETag) or If-Modified-Since. If the content hasn't changed, the origin responds with 304 Not Modified and no body, saving bandwidth. If it has changed, the full fresh response is returned. This is bandwidth-efficient but adds latency from the origin round-trip. Ideal for large payloads that change infrequently, such as user avatars or document attachments.