Edge caching looks easy until it isn't. You set a TTL, switch on the CDN, watch the hit ratio climb, and for a few weeks nothing breaks. Then a price change ships, a new region goes live, or someone adds a personalization header, and customers in three countries start seeing last week's inventory. Most edge caching failures aren't exotic. They're the same handful of mistakes, repeated in slightly different shapes.
Here are the seven that cause the most trouble, and the fixes that hold up in production.
1. Treating Every Response as Cacheable by Default
The fastest way to serve wrong content is to let the edge cache things it should never touch: carts, account pages, checkout confirmations, anything behind a session cookie. A response carrying Set-Cookie is a strong hint that it isn't shareable between users, yet plenty of setups cache it anyway because a framework emitted no explicit directive.
Fix this by inverting the default. Serve dynamic and authenticated routes with Cache-Control: private, no-store, then opt specific routes into shared caching deliberately. If your CDN has a "cache everything" rule, treat it as a loaded weapon: it should apply only to paths you have audited. Check what your origin actually emits with a quick curl -I against a few representative URLs before you blame the edge for anything.
2. Building a Cache Key That Ignores What Changes the Response
A cache key is a promise: same key, same response. Break that promise and you either serve the wrong variant to someone or destroy your hit ratio by fragmenting the cache into uselessness.
The usual culprits are unkeyed inputs. A currency query parameter, an A/B bucket, a device class, or an Accept-Language header that changes the rendered page — if the origin varies on it and the key doesn't include it, you'll eventually serve the wrong thing.
Practical key hygiene
- Normalize before you key: strip tracking parameters like utm_*, gclid, and fbclid, and sort the remaining query parameters alphabetically.
- Use Vary deliberately. Vary: User-Agent is close to disabling your cache, because User-Agent strings are nearly unique. Vary on a normalized device or locale header instead.
- Keep Vary: Accept-Encoding — most CDNs handle it at the edge layer anyway — and avoid stacking Vary fields you don't need.
- Push variant logic into the URL when you can. /pricing?currency=eur is easier to cache and purge correctly than a header-driven variant.
3. Using One TTL for Everything
A single blanket TTL is a symptom of not thinking about content lifecycle. Static assets with hashed filenames should live for months. Marketing HTML might want 60 seconds. A price or availability endpoint might want 30 seconds at the edge with revalidation in the background.
Learn the difference between the browser TTL (max-age) and the shared or edge TTL (s-maxage). Setting s-maxage=30, max-age=300 lets the edge refresh frequently while browsers hold a copy for longer. Add stale-while-revalidate so users get an instant response while the edge fetches a fresh one in the background, and stale-if-error so an origin hiccup doesn't turn into an outage. Add a little jitter to TTLs on high-traffic keys so thousands of objects don't expire in the same second.
4. Invalidation That Amounts to "Purge Everything"
A full purge feels safe and is usually the worst option. Every request then lands on the origin at once, latency spikes, and you've traded a stale-data problem for an availability problem.
Tag-based invalidation is the fix. Most CDNs let you attach logical keys to a response — surrogate keys, cache tags, whatever your provider calls them — and purge by tag later.
If you can't say exactly which objects a content change affects, you don't have an invalidation strategy. You have a reset button.
A workable pattern: tag every cacheable response at the origin with the entities it depends on (product:1234, category:shoes, nav:global), purge those tags when the underlying data changes, and keep TTLs short enough that a missed purge self-heals within minutes. Test purges in staging with real tags, because silent purge failures are common and invisible.
5. Trusting Client Headers When Building a Response
Cache poisoning at the edge rarely involves exotic exploits. It usually starts with an origin that reflects a request header into a cacheable response: an absolute redirect built from X-Forwarded-Host, a canonical link built from Host, a script tag built from X-Original-URL.
If that header isn't part of the cache key, one crafted request can plant a poisoned response that every subsequent visitor receives. Normalize or strip forwarding headers at the edge, never let them influence output, and make sure any header that genuinely changes the response appears in the cache key. Review redirect logic specifically — it's the most common injection point.
6. Letting a Cold Cache Hit the Origin All at Once
Right after a purge, a deploy, or a mass expiry, every edge location wants the same object simultaneously. Without protection, that stampede reaches your origin as a wave of identical requests.
Layer your defenses: request coalescing so concurrent misses for the same key collapse into one origin fetch, an origin shield or tiered cache so regional POPs share a single upstream, and leases at the origin for expensive endpoints. Combine that with stale-if-error and you can survive both traffic spikes and origin restarts.
7. Flying Blind on What the Edge Is Serving
You cannot fix what you don't measure. Track hit ratio by content type, origin offload percentage, revalidation rate, purge volume, and origin 5xx rates — separately, not as one blended number.
Also check from more than one place. A cache that behaves perfectly in Frankfurt can misbehave in Singapore because of a different POP configuration or a rule that wasn't replicated. Synthetic checks from several regions plus real user monitoring will catch regional drift that a single dashboard hides.
A Short Checklist Before Your Next Deploy
- Confirm every cacheable route has an explicit directive — no accidental caching of authenticated or personalized responses.
- Verify the cache key covers every input that changes the output, and that tracking parameters are stripped.
- Set separate browser and edge TTLs, with stale-while-revalidate and stale-if-error where it helps.
- Make sure tagging and tag-based purge work end to end in staging.
- Check that forwarding headers can't influence a cacheable response.
- Confirm coalescing or shielding is on for your heaviest endpoints.
- Look at hit ratio and origin load for at least a week after any routing or caching rule change.
None of this is glamorous work. But edge caching rewards the boring disciplines — explicit defaults, honest keys, targeted purges, and a dashboard you actually read. Get those right and the edge quietly does its job, which is exactly what you want from it.
Photo: Kranich17 / Pixabay
