CDN and Edge Caching: Reducing Latency for Global Users
Fast recall
Quick revision
Core answer
stale-while-revalidate beats explicit purges for most use cases).Edge caching mechanics, cacheability rules (`Cache-Control`, `Vary`), TTL strategy, invalidation, and origin-shield patterns.
Caching personalized responses without `Vary` or auth-token consideration (cross-user data leak), or relying on explicit purges for high-churn content.
Discuss `stale-while-revalidate`, multi-CDN steering, edge compute (workers/functions) for personalization at the edge, and content-addressed asset URLs (`app.abc123.js`) so cache is effectively forever.
Interview-ready guide
Interview answer
The why
Speed of light through fiber across continents is hundreds of milliseconds round-trip; load 50 assets and you're at 12+ seconds before any compute. CDNs put cached content within ~30ms of the user via edge POPs. Second benefit: scale absorption — a viral page served from edge means origin sees a tiny fraction of total traffic.
What belongs on CDN
- Always: static assets (JS/CSS/images/fonts), video segments, public API responses
- With care: HTML for mostly-static pages, search results for popular queries, geo-targeted
- Never: per-user authenticated, mutations, very low-traffic dynamic
Cache-Control is the key knob
public, max-age=60, stale-while-revalidate=120for cacheable API responsespublic, max-age=31536000, immutablefor content-addressed static assetsprivate, max-age=10for personalizedVaryonly on headers that genuinely affect output — NEVER on cookies or auth (cardinality explosion + cross-user leak risk)
Content-addressed URLs
app.abc123.js so URL changes when content changes; cache forever; no invalidation needed; old URL still valid for in-flight users. Webpack/Vite do this automatically.
Multi-tier topology
- Edge POP (city) → Regional shield (continent) → Origin
- Edge hits ~80% for popular content; shield aggregates misses; origin sees ~5-10% of total
- Shield also defends against thundering herd — viral video's segment hits origin once, not from 200 edges simultaneously
Invalidation — TTL first, purge second
- TTL with stale-while-revalidate is the default — user gets instant stale response, CDN refreshes in background
- Explicit purge is slow (seconds-to-minutes globally), quota-limited; reserve for emergencies
- Tag-based purging for catalog-wide updates (Cache-Tag / Surrogate-Key)
Edge compute for personalization
- Cloudflare Workers / Fastly Compute@Edge run code at the POP
- Cache the base HTML aggressively; inject user-specific bits at edge using cookies
- Public-content cache hit rate with per-user personalization
Multi-CDN
- 2-3 providers; DNS or client-side steering picks fastest/cheapest per viewer
- Resilience: one provider down doesn't take you down
- Cost arbitrage across regions
Failure handling
stale-if-errorserves stale during origin outage- Cache poisoning: strict key normalization + edge request validation
- Geo POP outage: CDN auto-routes to next-nearest
Recommendation
Use a CDN for any static asset, video segment, or cacheable API response. Set short `max-age` with `stale-while-revalidate` for dynamic content; content-address static assets to cache forever. Use a multi-tier topology with origin shield to protect origin from viral spikes. Reach for explicit purges only in emergencies; everything else is TTL + SWR + content addressing. That's how Netflix, Cloudflare, and modern web stacks run.
CDN and Edge Caching: Reducing Latency for Global Users
Direct Answer
A CDN is a globally distributed network of edge POPs that cache content close to users. Latency drops because requests terminate within ~10–50 ms of the user instead of crossing oceans. Use a CDN for static assets (JS/CSS/images), video segments (immutable HLS chunks), public API responses with cacheable shapes, and origin shielding even for dynamic content. The key levers are the Cache-Control header, cache key design (URL + a few headers), and invalidation strategy (short TTL + stale-while-revalidate beats explicit purges for most use cases).
Common Mistakes & Pitfalls
Caching personalized responses without Vary or auth-token consideration (cross-user data leak), or relying on explicit purges for high-churn content.
Check your understanding
Answer these without looking back at the article.
- Design the cache strategy for a personalized news feed where 90% of items are public but the ranking is per-user.
- How would you structure Cache-Control headers for an e-commerce product page with prices that change every few minutes?
- Compare CDN purge-by-tag vs short TTLs — when does each win?
- How do you keep a CDN's cache warm after a deploy that invalidates everything?
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.