Edge Caching

The core mechanism of edge caching relies on Points of Presence (PoPs) distributed globally. When a user requests content, the Anycast DNS system routes them to the nearest available edge server rather than the origin. This reduces Round-Trip Time (RTT) from potentially hundreds of milliseconds to single digits. For a user in Tokyo accessing a site hosted in Virginia, a cached response from a local Tokyo PoP eliminates trans-Pacific latency, turning a 150ms delay into a sub-10ms response.

An edge server identifies unique objects via a cache key, typically the URL. However, dynamic content requires cache key manipulation to normalize trivial variations that would otherwise fragment the cache and reduce hit ratios. This includes:

• Stripping irrelevant query parameters (e.g., utm_source)
• Normalizing header order
• Collapsing protocol variants (HTTP/HTTPS) The Vary header instructs the cache to store multiple variants of a response based on specific request headers, such as Accept-Encoding for gzip vs. brotli compression.

To protect the origin server from a thundering herd of requests during a cache miss, modern CDNs employ a shield or parent cache layer. Instead of every edge PoP forwarding a miss directly to the origin, they request it from a centralized intermediate cache layer. This L1/L2 cache architecture ensures the origin sees only one request per object globally, drastically reducing load. The shield absorbs the fan-out, consolidating thousands of concurrent edge misses into a single origin fetch.

When content updates, stale copies must be removed immediately. Modern edge networks support instant purge via API, allowing removal of specific objects (by URL) or entire cache tags in under a second globally. Surrogate-Key tagging allows grouping diverse URLs under a single tag (e.g., product-123). Purging that tag invalidates the product page, its JSON API response, and any related fragments simultaneously, enabling precise, high-velocity cache management without full-site flushes.

Edge caching has evolved beyond static asset delivery to include serverless edge compute. Platforms like Cloudflare Workers or Fastly Compute@Edge allow running custom logic at each PoP. This enables:

• A/B testing without client-side flicker
• Geolocation-based content personalization
• Full API gateway logic at the edge
• Header-based authentication before cache lookup This blurs the line between a cache and an application server, moving dynamic logic closer to the user.

A directive specifying how long a cached object remains fresh before requiring revalidation from the origin server. Key aspects:

• Set via Cache-Control headers (e.g., max-age=3600)
• Balances freshness against origin load
• Can be overridden at the CDN edge layer
• Shorter TTLs increase origin traffic; longer TTLs risk staleness

Edge platforms often apply a minimum TTL to prevent excessive origin requests during traffic spikes.

An additional caching layer between edge PoPs and the origin server that collapses multiple requests into a single origin fetch. Benefits:

• Reduces origin load by up to 70% compared to direct edge-to-origin requests
• Protects origin from thundering herd problems during cache misses
• Acts as a request coalescer when many edges request the same object simultaneously

Common in multi-tier CDN architectures where a central cache node shields the origin infrastructure.