What Are Edge Caching Strategies?
Learn how edge caching and CDNs cut latency, cache-key design, TTLs, invalidation, and stale-while-revalidate.
Expected Interview Answer
Edge caching stores copies of responses at CDN points of presence physically close to users, so most requests are served from a nearby edge node instead of round-tripping to the origin, cutting latency and origin load dramatically.
A CDN operates hundreds of edge locations worldwide; when a request arrives, the nearest edge node checks whether it already holds a fresh copy of the response and serves it directly on a cache hit, only forwarding to the origin server on a cache miss and then storing the result for subsequent requests. Strategies include setting cache-control headers and TTLs to control freshness, cache key design (varying by query params, headers, or cookies) to avoid serving the wrong content to the wrong user, stale-while-revalidate to serve slightly stale content while refreshing in the background, and explicit purge/invalidation APIs for content that changes before its TTL expires. Static assets (images, JS bundles, CSS) are cached aggressively with long TTLs and versioned filenames, while dynamic or personalized content needs careful cache-key partitioning or is bypassed entirely. Done well, edge caching can absorb the vast majority of read traffic, reducing origin load and latency simultaneously.
- Reduces latency by serving responses from a location physically near the user
- Cuts load on origin servers since most reads are absorbed at the edge
- Improves resilience by keeping content available even if the origin has a brief outage
- Lowers bandwidth costs by avoiding repeated origin fetches for the same content
AI Mentor Explanation
Edge caching is like a stadium stocking cold drinks at concession stands scattered throughout the ground instead of making every fan walk to a single central storeroom. A fan grabs a drink from the nearest stand instantly on a hit, and only if that stand has run out does someone fetch more from the central store, restocking the stand for the next fan. Popular drinks get restocked constantly with a short freshness window, while rare items might sit unstocked and go straight to the central store each time. That distributed, near-the-fan stocking with a fallback to the central store is exactly how edge caching speeds up content delivery.
Step-by-Step Explanation
Step 1
Request hits nearest edge node
A client request is routed via DNS/anycast to the geographically closest CDN point of presence.
Step 2
Cache key lookup
The edge node computes a cache key (URL plus relevant headers/query params) and checks for a fresh stored response.
Step 3
Serve on hit, fetch on miss
A fresh hit is served immediately; a miss (or stale entry) triggers a fetch from the origin, which is then cached for future requests.
Step 4
Expire or invalidate
Entries expire per TTL/cache-control headers, or are explicitly purged via an invalidation API when content changes early.
What Interviewer Expects
- Explains cache hit vs miss and the role of TTL/cache-control headers
- Distinguishes caching static assets aggressively vs handling dynamic/personalized content carefully
- Mentions cache key design and invalidation/purge strategies
- Names a real CDN example: Cloudflare, Fastly, Akamai, CloudFront
Common Mistakes
- Caching personalized or authenticated responses under a shared cache key by mistake
- Not mentioning invalidation/purge for content that changes before the TTL expires
- Treating the CDN edge as a database instead of a read-through cache layer
- Ignoring stale-while-revalidate as a way to balance freshness and latency
Best Answer (HR Friendly)
“Edge caching stores copies of content at servers physically close to users around the world, so most requests are answered nearby instead of traveling all the way back to the original server. This makes pages load faster and takes a lot of pressure off the origin, as long as you are careful about how long content stays cached and when it needs to be refreshed.”
Code Example
rules:
- path: "/static/*"
cacheControl: "public, max-age=31536000, immutable"
edgeTtl: 31536000
- path: "/api/products"
cacheControl: "public, max-age=60, stale-while-revalidate=300"
edgeTtl: 60
cacheKey:
queryParams: ["category", "page"]
- path: "/api/account/*"
cacheControl: "private, no-store"
edgeTtl: 0Follow-up Questions
- How would you cache personalized content without leaking one user's data to another?
- What is stale-while-revalidate and how does it improve perceived latency?
- How do you invalidate an edge cache globally the moment content changes?
- How does edge caching interact with a CDN's origin shield layer?
MCQ Practice
1. What happens on an edge cache miss?
On a miss the edge node forwards the request to the origin, returns the response to the client, and caches it for subsequent hits.
2. Which technique lets an edge node serve slightly outdated content while refreshing it in the background?
Stale-while-revalidate serves a cached (stale) response immediately while asynchronously fetching a fresh copy for next time.
3. Why should personalized or authenticated responses generally bypass a shared edge cache?
Caching per-user content under a shared cache key risks leaking one user's response to another; it needs per-user keys or must bypass the cache.
Flash Cards
What is a cache hit? — When the edge node already holds a fresh copy of the response and serves it without contacting the origin.
What is stale-while-revalidate? — Serving a stale cached response immediately while refreshing it from the origin in the background.
Why is cache key design important? — Because varying it correctly (headers, query params) prevents serving the wrong content to the wrong user.
Main benefit of edge caching? — Lower latency and reduced origin load by serving most reads from a nearby CDN node.