Cache Invalidation via Surrogate Keys: Edge Architecture and Purge Mechanics

Interview Part 1: Edge Caching Bottlenecks

Q: Why does traditional TTL-based caching fail for modern high-concurrency HTTP APIs?

Answer: Traditional Time-To-Live mechanisms force engineers into a rigid tradeoff between freshness and origin server load. When you rely solely on TTLs, short durations like five seconds reduce latency gains while subjecting database clusters to stampedes during traffic spikes. Conversely, setting long TTLs leaves downstream consumers holding stale responses whenever underlying data changes unpredictably. Flash sales, real-time inventory updates, and multi-tenant settings suffer when cache purging requires clearing entire URL prefixes. Soft purges help by serving stale content while fetching fresh data, but global wildcard purges remain expensive across distributed edge nodes. Invalidating single cached objects by URL path breaks down as soon as a single database row maps to dozens of API endpoints, search indexes, and custom JSON views across your CDN.

Q: How do Surrogate Keys solve the object dependency problem at the CDN tier?

Answer: Surrogate Keys decouple cache invalidation from URL paths by assigning tagging headers directly to HTTP responses at origin servers. When an application constructs a payload, it appends a Surrogate-Key header listing unique identifiers for every data model involved in generating that response. The edge proxy ingests these headers, indexes the cached object against those key tags, and strips the header before forwarding the body to the client. When a backend event mutates a specific record, your service sends a single API request targeting that specific tag. The CDN invalidates every cached endpoint associated with that identifier instantly, regardless of the request URL. This targeted approach enables long TTLs by default, eliminating blanket cache flushes while guaranteeing instant data updates across edge locations.

Interview Part 2: Surrogate-Key Implementation

Q: What does a production workflow look like when issuing targeted purges?

Answer: In production, your backend application framework automatically attaches surrogate keys during response serialization. For instance, an ecommerce item detail page might output a Surrogate-Key header listing product-8910, category-44, and brand-12. When an administrator modifies the product price in a CMS or database transaction, the application fires an HTTP POST request to the CDN API or Varnish instance targeting tag product-8910. The edge immediately invalidates all cached responses tagged with product-8910, while leaving category-44 and brand-12 cached for other queries. This targeted approach guarantees that related endpoints update without clearing unrelated site pages.

Here is a practical example of executing a targeted key purge via the CDN REST API:

curl -X POST \
  -H "Fastly-Key: $FASTLY_API_KEY" \
  -H "Accept: application/json" \
  "https://api.fastly.com/service/$FASTLY_SERVICE_ID/purge/product-8910"

This API call completes in milliseconds across all global edge points without stressing origin databases.

Q: What operational pitfalls must network engineers watch for when adopting key-based invalidation?

Answer: The primary risk stems from header size constraints and key cardinality explosion. CDNs impose strict header size limits, typically between eight and sixteen kilobytes. If an API endpoint aggregates hundreds of database entities, the resulting Surrogate-Key header will exceed buffer limits, causing upstream proxies to drop responses or return HTTP 502 errors. Engineers must group granular keys into higher-level logical buckets or hash long identifier lists to stay well within header boundaries. Another trap involves cache key normalization; trailing slashes or unsorted query parameters can duplicate cache entries under the same surrogate keys, multiplying memory consumption at the edge. Monitoring purge queue latencies and tracking cache hit rates per surrogate tag ensures your invalidation pipeline remains reliable under heavy traffic.

Tagging HTTP responses with precise entity keys transforms cache management from guessing TTL expiration into deterministic, event-driven data distribution.