Edge Caching at the CDN
Edge caching stores responses on CDN nodes close to users, cutting latency and origin load, but demands careful cache keys and invalidation.
Definition
Edge caching is the practice of storing responses at points of presence near end users so subsequent requests are answered without reaching the origin server.
Context and scope
It is applied to static assets, public API responses, and any content that many users request identically.
Common misconceptions
- every response can be cached at the edge safely
- purging a URL removes all of its variants at once
Anti-patterns
- caching personalised responses under a key that omits the user
- relying only on time-based expiry to remove changed content
Related concepts
Related examples
Authoritative source
Definition
Edge caching is the practice of storing responses at points of presence near end users so subsequent requests are answered without reaching the origin server.
It is applied to static assets, public API responses, and any content that many users request identically. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
Correctness depends on the cache key, so responses that vary by header, cookie, or geography must either make that variance part of the key or be marked private.
Invalidation is harder at the edge than in a single cache, so explicit purge by tag or surrogate key is usually more reliable than waiting for expiry.
Trade-offs and alternatives
Stale-while-revalidate lets an edge serve a slightly old copy while fetching a fresh one in the background, hiding origin latency from users during revalidation. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that every response can be cached at the edge safely. Another is that purging a URL removes all of its variants at once. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to caching personalised responses under a key that omits the user and to relying only on time-based expiry to remove changed content. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Request Deduplication, Cache-Control Directives, Cache Key Normalisation.