Cache Invalidation

The most fundamental strategy where cached objects are assigned a finite lifespan. Once the TTL expires, the object is considered stale and is either passively removed or actively refreshed upon the next request.

• Absolute TTL: The object expires at a specific wall-clock time, useful for content tied to a fixed event like a sale end date.
• Sliding TTL: The expiration timer resets with each access, ideal for session data that should persist as long as the user is active.
• Origin Shield: A central cache layer that combines requests, reducing the load on the origin server when multiple edge nodes simultaneously request an expired object.

A precise invalidation method where cached objects are tagged with metadata keys at write time. An administrator can then send a single purge command referencing a tag to instantly remove all associated objects, regardless of their URL.

• Surrogate Keys: A single HTTP response header (e.g., Surrogate-Key: user-123 post-456) can contain multiple tags, allowing for granular, cross-object purging.
• Soft Purge: Marks the content as stale but serves the old version while asynchronously fetching a new one from the origin, preventing a thundering herd on the origin server.
• Hard Purge: Immediately removes the object from cache, causing the very next request to block while waiting for a fresh copy from the origin.

A straightforward strategy that invalidates cached resources by matching their exact URL or a URL prefix. This is the simplest method to implement but can be imprecise for highly dynamic, personalized content.

• Exact URL Purge: Targets a single resource, such as /api/profile/user-123.json, ensuring only that specific object is removed.
• Wildcard Prefix Purge: Removes all objects under a path, like /products/electronics/*. This is efficient for clearing a category but can inadvertently evict non-stale, cache-warm objects.
• Limitations: This method struggles with content that varies by headers or cookies, as the URL alone does not uniquely identify a personalized variant of a page.

A caching directive that instructs the CDN to immediately serve a stale (expired) object to the user while simultaneously re-fetching a fresh copy from the origin in the background. This masks origin latency entirely from the end-user.

• Cache-Control Header: Implemented via Cache-Control: max-age=60, stale-while-revalidate=3600. This allows serving a stale object for up to an hour while a single background refresh occurs.
• Stale-If-Error: A companion directive that permits serving a stale object if the origin server returns a 5xx error, acting as a circuit breaker for backend failures.
• Personalization Impact: For personalized content, SWR must be paired with a Vary: Cookie header to ensure a user's stale version is not served to a different user during the revalidation window.

A real-time strategy where a change in the system of record (e.g., a CMS or database) triggers an immediate, targeted purge via a webhook or message queue. This ensures the cache is updated within milliseconds of a content change.

• Change Data Capture (CDC): Monitors the database's transaction log for INSERT, UPDATE, or DELETE operations and translates them into specific cache purge commands.
• Webhook Architecture: The CMS fires an HTTP POST to a /purge endpoint whenever an author publishes or updates content, carrying the tags or URLs to invalidate.
• Debouncing: A critical safeguard that aggregates rapid-fire events (e.g., 10 saves in 2 seconds) into a single purge action to avoid overwhelming the origin with unnecessary re-fetches.

Instead of actively purging an old object, this strategy changes the identifier (cache key) used to store it. The old object is left to expire naturally while new requests fetch the fresh resource under a new key, making invalidation instantaneous and atomic.

• Content Hash Fingerprinting: A build process generates a unique hash of a file's contents (e.g., main.a1b2c3d.js). When the file changes, the hash changes, creating a brand new URL that is guaranteed to be a cache miss.
• Query String Versioning: Appending a version parameter like ?v=2.1 to a URL forces a cache miss. This is simple but can be less reliable if query strings are stripped by intermediary proxies.
• Vary Header Strategy: For personalized content, the Vary: Cookie header makes the cookie value part of the cache key, ensuring each user's personalized version is stored as a separate, independently addressable object.

The fundamental mechanism that assigns an expiration timestamp to cached objects. When the TTL expires, the object is considered stale and must be revalidated or purged.

• Absolute TTL: Object expires at a fixed date/time
• Sliding TTL: Expiration resets on each access
• Typical values: 5 minutes for personalized content, 24 hours for static assets

Setting TTL too high serves stale content; too low negates caching benefits.

HTTP response directives that govern how downstream caches (browsers, CDNs) store and revalidate content. Critical for programmatic invalidation strategies.

• max-age: Maximum time in seconds a resource is considered fresh
• s-maxage: Overrides max-age specifically for shared CDN caches
• no-cache: Requires revalidation before each use
• must-revalidate: Forces stale content to be rechecked at origin
• stale-while-revalidate: Serves stale content while asynchronously fetching fresh version

Proper header configuration prevents the need for manual purge operations.

A mechanism for selective invalidation by associating cached objects with descriptive labels. Instead of purging entire cache zones, you target only affected content.

• Tag a page with article-123, category-tech, author-jane
• When article 123 updates, send a single purge for article-123
• All related pages (listings, RSS feeds) tagged with article-123 are invalidated simultaneously

CDN support: Fastly (Surrogate Keys), Cloudflare (Cache-Tags), Akamai (Cache Tags). Essential for personalized content where full purges are prohibitively expensive.

A caching strategy that prioritizes availability over strict consistency. When a cached object expires, the CDN immediately serves the stale version to the user while asynchronously fetching a fresh copy from origin.

• User impact: Zero latency penalty on cache miss
• Origin protection: Prevents thundering herd on backend during mass expiration
• Header syntax: Cache-Control: max-age=60, stale-while-revalidate=3600

This pattern is critical for personalized content where origin regeneration is computationally expensive. The user sees slightly outdated content for one request rather than waiting seconds for personalization logic to execute.

Two opposing strategies for synchronizing cache with the source of truth during data mutations.

Write-Through:

• Data written to cache and origin simultaneously
• Cache is always consistent
• Higher write latency

Write-Back (Write-Behind):

• Data written to cache immediately, origin updated asynchronously
• Lower write latency, risk of data loss on cache failure
• Requires sophisticated invalidation if async write fails

For personalization engines, write-through ensures user profile updates are immediately reflected, while write-back can batch analytics data.

A cascading failure scenario where mass simultaneous cache expiration causes a flood of requests to hit the origin server simultaneously.

• Trigger: Popular content with identical TTL expiring
• Result: Origin overload, timeout cascades, potential outage
• Mitigations:
  • TTL jitter: Randomize expiration by ±10%
  • Stale-while-revalidate: Absorbs spike with stale content
  • Request coalescing: Collapse parallel requests into single origin fetch
  • Locking/Probabilistic early expiration: Refresh cache before hard expiry

Critical consideration when invalidating personalized content for large user segments simultaneously.