An edge cache is a cache that runs on servers at the edge of a content delivery network, close to end users, and stores copies of responses from an origin server so that later requests can be answered locally. In content delivery, it is the component that turns geographic proximity into speed: a cache hit at a nearby point of presence avoids a long round trip to the origin and removes load from it.
Edge caches follow the HTTP caching model defined in RFC 9111, so the origin controls what may be stored and for how long through response headers. The CDN adds its own configuration on top, such as cache keys, purging and tiered caching, which decides how effectively the edge serves traffic.
How an edge cache serves a request
A user’s request is steered by DNS or anycast routing to a nearby point of presence (PoP). The edge server computes a cache key, usually from the scheme, host, path and query string, and looks it up in its storage. If a fresh copy exists, it returns it immediately; otherwise it fetches the object, stores it if allowed, and then responds.
Storage is typically two-tiered within each server: a small, very fast memory layer for the hottest objects and a larger SSD layer for the long tail. When space runs out, an eviction policy such as least recently used removes objects regardless of their remaining lifetime, so a long TTL does not guarantee that an object stays cached.
The table lists the cache states that appear in CDN logs and response headers.
| Outcome | What happened | Origin contacted |
|---|---|---|
| Hit | Fresh copy served from the edge | No |
| Miss | No copy stored, fetched from upstream | Yes |
| Expired or stale | Copy existed but was no longer fresh | Yes, often as revalidation |
| Revalidated | Origin confirmed copy with 304 Not Modified | Yes, without the body |
| Bypass | Rules forbid caching this request | Yes, every time |
Freshness, revalidation and cache control
The origin sets freshness with the Cache-Control header. The s-maxage directive applies to shared caches such as CDNs and overrides max-age, which lets a site cache at the edge longer than in browsers. Many CDNs also honor a dedicated CDN-Cache-Control header that targets only the CDN layer.
| Directive | Effect at the edge | Typical value or use |
|---|---|---|
| s-maxage | Freshness lifetime for shared caches | 60 seconds to 1 year |
| max-age | Freshness when s-maxage is absent | Seconds, for example 3600 |
| no-store | Must not be stored at all | Personal or sensitive responses |
| private | Only browser caches may store it | Pages for a signed-in user |
| stale-while-revalidate | Serve stale copy while refreshing | Seconds to minutes |
| stale-if-error | Serve stale copy if origin fails | Minutes to hours |
Once a copy expires, the edge can revalidate it with conditional requests using ETag or Last-Modified validators. A 304 response refreshes the copy cheaply. The stale-while-revalidate and stale-if-error extensions let the edge hide origin latency and outages from users for a bounded time.
Edge cache compared with other caches
A web response may be cached at several places on its way to the user. The edge cache is the shared cache closest to the user, which distinguishes it from both the private browser cache and caches near the origin.
| Cache location | Shared between users | Main purpose |
|---|---|---|
| Browser cache | No | Instant repeat views for one user |
| Edge cache at a PoP | Yes | Low latency for users in a region |
| Origin shield or tier cache | Yes | Collapses misses from many PoPs |
| Reverse proxy at the origin | Yes | Protects application servers |
| Application or database cache | Internal only | Avoids repeated computation |
An origin shield sits between edge PoPs and the origin. Without it, a newly published file can cause a miss in every PoP at once; with it, those misses collapse into one origin request, which matters for large catalogs with low per-PoP popularity.
Designing content for a high hit ratio
The cache hit ratio is the share of requests answered from the edge. Static assets commonly reach very high ratios, while HTML and API traffic vary widely with personalization and TTL choices. The byte hit ratio is often more relevant for cost, because a few large files can dominate egress.
- Use versioned file names such as a content hash for scripts and images, then cache them for a year.
- Normalize the cache key by ignoring tracking parameters and sorting query strings.
- Keep Vary narrow; varying on full User-Agent fragments the cache into thousands of variants.
- Purge by tag or path after deployments instead of relying on short TTLs everywhere.
- Split personalized fragments from shared page shells so the shell remains cacheable.
Risks and common mistakes
The most serious edge cache failure is serving one user’s private data to another. It happens when a personalized response lacks private or no-store and the CDN stores it under a shared key. Web cache deception and cache poisoning attacks exploit similar gaps, for example unkeyed headers that change the response.
| Symptom | Likely cause | Fix |
|---|---|---|
| Users see someone else’s account page | Personalized page cached as shared | Mark it private and bypass the cache |
| Old content after deployment | Long TTL without purge | Purge on release or version URLs |
| Low hit ratio on static files | Random query parameters in the key | Strip unneeded parameters |
| Origin overload after purge | All PoPs miss at once | Enable an origin shield and request collapsing |
Put simply
Picture a popular book that everyone in the country wants. Instead of shipping each copy from the publisher’s single warehouse, the publisher keeps stocks in local shops in every city. Most readers get the book the same day from the shop nearby, and the warehouse is rarely bothered.
An edge cache is that local shop for websites. It keeps copies of pictures, videos and pages near the people who ask for them. The website itself decides how long each copy may stay on the shelf before it must be checked again, so readers get speed without seeing content that is badly out of date.
In practice
A retailer prepares for a seasonal sale that will bring several times its normal traffic. Product images and scripts already use hashed file names with a one-year TTL, but product pages are sent with no-cache, so every page view reaches the origin.
The team restructures the pages: a shared page shell is cached at the edge with s-maxage of 60 seconds and stale-while-revalidate of 300 seconds, while prices in the cart and stock badges load through a small uncached API. An origin shield collapses misses from all regions. During the sale, the edge answers the large majority of page requests, origin load stays within normal capacity, and a brief database slowdown goes unnoticed by shoppers because the edge keeps serving slightly stale but valid pages.