Surrogate Key

A surrogate key is a unique identifier assigned to a piece of content, not its location. When a single piece of data—like a product price or author bio—appears on hundreds of URLs, all those cached objects are tagged with the same key. Updating the source content requires sending a single purge command with that key, instantly invalidating every associated cached object across the entire CDN without needing to know their individual URLs.

Content is tagged with multiple surrogate keys representing different dimensions of its composition. A product detail page might be tagged with:

• product-12345 (the specific product)
• category-electronics (its parent category)
• brand-acme (the manufacturer)
• layout-pdp-v2 (the template version)

Updating the brand logo triggers a purge of brand-acme, instantly clearing every page, fragment, and API response associated with that brand across the entire site.

Unlike URL-based purging which requires wildcard patterns or explicit path lists, surrogate keys enable surgical precision. A single API response containing a list of articles can be tagged with each article's unique key. When one article is updated, only caches containing that specific article are invalidated, leaving all other list responses untouched. This eliminates the cache stampede and unnecessary origin load caused by broad, pattern-based purges.

The origin server communicates surrogate keys to the CDN via a dedicated HTTP response header, typically Surrogate-Key or Cache-Tag. The CDN edge node parses this header and indexes the cached object against every key in the space-delimited list. Example header:

Surrogate-Key: article-42 author-7 category-ai frontpage

This mechanism requires zero client-side logic and works transparently with standard HTTP caching semantics.

Surrogate keys integrate directly into event-driven architectures. A Content Management System emits an article.updated event containing the article's surrogate key. A lightweight purge service consumes this event and calls the CDN's purge API with that single key. The entire invalidation workflow—from content save to global cache purge—completes in under 150 milliseconds, enabling near-real-time content updates without full site rebuilds.

In complex architectures with layered caching—browser cache, CDN edge, CDN shield, and origin cache—surrogate keys maintain consistency across all tiers. A purge request targeting a surrogate key propagates through the CDN's internal hierarchy, clearing every cache node that holds objects tagged with that key. This prevents the stale content from being re-served from an upstream cache layer after only the edge is cleared.

The process of purging or updating outdated data from a cache when the source content changes. Surrogate keys enable targeted invalidation—sending a single purge request for a key like post-123 removes all associated cached objects (HTML page, JSON API response, mobile fragment) simultaneously, without needing to track their individual URLs. This contrasts with URL-based purging, which requires explicit knowledge of every cached path.

A markup language for dynamic content assembly at the CDN edge. ESI tags instruct edge servers to compose a page from multiple fragments, each with independent cache policies. Surrogate keys are critical here: a single page assembled from fragments tagged with keys like header-global, product-456, and footer-promo can be partially invalidated when any constituent piece changes, avoiding full-page rebuilds.

A formal definition of content types, their attributes, and relationships. Surrogate keys map naturally to this model: each content entity (e.g., an author, category, or product) receives a unique key. When that entity updates, all pages and fragments referencing it are purged. This creates a graph-based invalidation pattern where content relationships directly drive cache lifecycle.

A strategy for aggregating content from disparate source repositories into a unified virtual layer. Surrogate keys serve as the universal identifier across federated systems. A product detail page pulling data from a PIM, CMS, and pricing engine can be tagged with all three source keys, ensuring that an update in any back-end system triggers precise cache invalidation for the assembled page.

The HTTP header that dictates caching behavior. While Cache-Control defines how long an object lives (max-age, s-maxage), the Surrogate-Key header defines what group it belongs to. Together they form a complete caching strategy: TTLs handle temporal expiration, while surrogate keys handle event-driven, content-based invalidation triggered by upstream data changes.