Edge Cache

What is an edge cache?

An edge cache is a cache located at a CDN edge location — one of the many geographically-distributed points of presence a content-delivery network operates around the world — so that content can be served to a user from a nearby city rather than from a distant origin server. When a user requests a cached asset, it’s delivered from the closest edge (low latency), and the origin is never touched. Edge caching is the core mechanism that makes CDNs fast: it moves copies of content physically close to users, cutting the round-trip distance from thousands of miles to tens.

Why it works — latency and origin offload

Edge caching delivers two big wins. Latency reduction: network requests are bounded by the speed of light and the number of hops, so serving a file from an edge node in the user’s region instead of an origin on another continent can cut hundreds of milliseconds — a major factor in page-load speed and user experience. Origin offload: because the edge answers most requests, the origin server sees only a fraction of the traffic (cache misses and un-cacheable requests), which dramatically reduces origin load and cost and lets a modest origin serve a global audience — and it’s a key defense against traffic spikes and DDoS, since the distributed edge absorbs the flood. This is why virtually all static content (images, CSS, JS, video, downloads) is served from edge caches, and increasingly dynamic and personalized content too via smarter edge logic. Whether something is cached at the edge, and for how long, is governed by Cache-Control and related HTTP headers on the response (or CDN configuration) — the origin tells the edge what’s cacheable and its TTL.

The realities: what to cache, and invalidation

Edge caching’s hard parts are the general caching hard parts, concentrated. Cache invalidation is the central challenge: when content changes at the origin, the stale copies sitting in edge caches worldwide must be refreshed or purged, or users keep seeing the old version. CDNs provide purge APIs to invalidate content, and the clean pattern for versioned assets is cache-busting via fingerprinted filenames (a new build produces app.a1b2c3.js, a new URL, so old cached copies simply age out and there’s nothing to purge) — mass-purging by URL is slower and can stampede the origin. Deciding what’s cacheable matters: static assets are easy, but caching user-specific or sensitive content at a shared edge is dangerous — a misconfiguration that caches a personalized page (with one user’s data) and serves it to others is a real and serious data-leak bug, so Cache-Control: private/no-store and correct cache-key/Vary handling are essential for anything user-specific. Other realities: cache hit ratio is the metric that matters (a low hit ratio means most requests still hit the origin, negating the benefit — often caused by overly-varied cache keys or too-short TTLs), the cold-cache/first-request case (the first user to a given edge for a given object gets a miss and origin fetch), and consistency across the many edge nodes (an update propagates to edges over time, not instantly). The recurring mistakes: caching personalized/sensitive responses at a shared edge (leaking data), poor invalidation so users see stale content, and cache keys so specific that the hit ratio collapses.

What people get wrong

• Caching personalized content at a shared edge — serving one user’s cached personal page to another is a serious data leak; mark user-specific responses private/no-store with correct Vary/cache keys.
• Weak invalidation: without proper purging or fingerprinted filenames, edge caches worldwide keep serving stale content after the origin updates.
• Killing the hit ratio — overly-specific cache keys or too-short TTLs send most requests to the origin anyway, negating the point of edge caching.

Primary source: Cloudflare Learning: What is a CDN edge server?