CDNs & edge caching
In one line
A CDN keeps copies of your content on servers in hundreds of cities so users are served from somewhere nearby, cutting latency and taking most of the load off your origin.
What it is
A Content Delivery Network is a large set of servers, grouped into points of presence (PoPs) around the world, that sit between users and your origin server. When a user requests a file, the nearest PoP serves it from its cache if it can, and only fetches from the origin on a miss.
What may be cached and for how long is controlled mostly by HTTP headers from the origin, such as Cache-Control: public, max-age=86400 or s-maxage for shared caches only. Content is identified by a cache key, usually the host and URL, optionally with some headers or query parameters.
Modern CDNs do more than cache files: they terminate TLS close to users, absorb DDoS attacks, run web application firewalls and can run code at the edge.
Why interviewers ask
Latency is bounded by distance: a round trip from Mumbai to a server in Virginia is around 200 ms, and a page needs several round trips. Interviewers expect CDNs in any design that serves images, video or static files worldwide, and they test whether you understand cache keys, TTLs, invalidation and what should not be cached.
How it works
- 1Users are routed to a nearby PoP, either by DNS returning a nearby edge IP or by anycast, where the same IP is announced from many locations and the internet's routing picks the closest.
- 2The PoP terminates TLS and computes the cache key for the request, for example https://img.shop.com/p/123.jpg.
- 3Cache hit: the PoP returns the stored copy immediately, usually in a few milliseconds.
- 4Cache miss: the PoP fetches from the origin (often via a regional mid-tier or origin shield cache, so many PoPs do not all hit the origin), stores the response according to its headers and returns it.
- 5When the TTL expires, the PoP revalidates with the origin using ETag or Last-Modified; an unchanged file costs only a small 304 response.
- 6To change content early, you either purge the URL through the CDN's API or, better for static assets, deploy files under new versioned names (app.3f9a1c.js) so old and new never conflict.
Worked example · One image requested by three users
- Origin is in Frankfurt. The image /p/123.jpg is served with Cache-Control: public, max-age=86400.
- User 1 in Singapore hits the Singapore PoP: miss. The PoP fetches from Frankfurt (about 160 ms round trip), stores the image and replies. Total about 200 ms.
- User 2 in Singapore requests the same image 5 minutes later: hit, served in about 10 ms. Origin is not touched.
- User 3 in Paris hits the Paris PoP: miss there (each PoP has its own cache), fetched from Frankfurt in about 15 ms and cached.
- After 1,000 Singapore requests that day, the origin has served the image to Singapore once: a 99.9 percent hit ratio for that PoP.
- The product photo is updated. Because the URL is the same, you purge /p/123.jpg; with versioned URLs like /p/123.v2.jpg no purge would be needed.
Picture it
Instead of every customer driving to the one central factory, the company stocks popular products in local shops in every town. The first customer in a town might wait while a shop orders an item, but everyone after that picks it up immediately, and the factory is not flooded.
Key patterns
Immutable versioned assets
When: JS, CSS, images and fonts that change on deploy
How: Put a content hash in the file name and cache for a year; deploys change names, so no purges are needed.
Short TTL plus stale-while-revalidate
When: Semi-dynamic pages like listings or news front pages
How: Cache for seconds to minutes and let the edge serve a slightly stale copy while it refreshes in the background.
Origin shield
When: Many PoPs would otherwise all miss to the origin
How: Route misses through one regional cache layer so the origin sees roughly one request per object.
Bypass for personalised data
When: Responses depend on the logged-in user
How: Mark them Cache-Control: private or no-store, or cache only the shared parts and fetch the personal parts from the client.
Real-world use
Netflix Open Connect
Netflix places its own caching appliances inside ISP networks and fills them with popular shows overnight, so most video streams come from a server inside or near your ISP rather than across the internet.
Cloudflare, Akamai, Fastly and CloudFront
These CDNs cache websites, images and downloads in hundreds of cities and also provide DDoS protection and WAF rules; Fastly is known for very fast purges, useful for news sites.
Software and game downloads
Operating system updates and game patches are served through CDNs, because millions of users download the same large files at the same time on release day.
Edge compute
Cloudflare Workers and Lambda@Edge run small functions in PoPs for redirects, A/B tests, authentication checks or personalised headers, without a trip to the origin.
In a project
An e-commerce site with users in India, Europe and the US serves everything from one origin in the US. Pages load slowly abroad, and sale days overload the origin.
- Put a CDN in front of the site with the origin as its backend and an origin shield region to collapse misses.
- Serve JS, CSS and images with content-hashed file names and Cache-Control: public, max-age=31536000, immutable.
- Cache product listing pages for 60 seconds at the edge (s-maxage=60) with stale-while-revalidate, but never cache carts, checkout or anything with a user's cookie.
- Keep the cache key small: ignore tracking query parameters like utm_source so they do not split the cache.
- Purge product pages through the CDN API when prices change, and track hit ratio and origin requests per second.
Impact: Median page load time abroad drops from about 3 seconds to under 1 second, the edge serves over 90 percent of requests, and the origin's load on sale days falls by an order of magnitude.
Trade-offs
Use it when
- Static assets, images, video and downloads for users spread across regions
- Traffic spikes or DDoS risk that the origin cannot absorb alone
- Public pages that are the same for many users for at least a few seconds
Avoid it when
- Personalised or sensitive responses unless headers clearly prevent shared caching
- Data that must be perfectly fresh, like stock balances, without a purge strategy
- Cache keys that include unneeded headers or query strings, which ruin the hit ratio
Cost: Hit latency is a few to tens of milliseconds; a miss costs the full trip to origin plus a little. Hit ratio is the key metric: at 95 percent, the origin sees only 1 in 20 requests.
Common mistakes
- Caching personalised pages and showing one user's data to another.
- Relying on purges for every deploy instead of versioned file names.
- Assuming a hit in one PoP means every PoP has the content; caches are per location.
- Ignoring query strings and cookies in the cache key, causing a near-zero hit ratio.
- Thinking a CDN only helps static files: it also speeds up dynamic requests through nearby TLS termination and optimised connections to the origin.
Interview questions
Quick revision
- CDN = many PoPs near users caching content from your origin.
- Routing: DNS steering or anycast.
- Cache-Control: public, max-age, s-maxage (shared caches), private, no-store.
- Versioned asset names plus long max-age beat purging.
- stale-while-revalidate keeps responses fast while refreshing.
- Origin shield collapses misses; hit ratio is the key metric.
- Never cache personalised responses in shared caches.
Check yourself
1. Which header lets a CDN cache a response for 60 seconds while browsers do not cache it at all?
2. What is the cleanest way to roll out a new version of app.js that is cached for a year?
3. A Singapore user gets a cache hit. A London user then requests the same file for the first time. What happens?
4. Which response should never be stored in a shared CDN cache?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.