Difficulty: Intermediate
What is a CDN and how does it work? How does a request get routed to the nearest edge, and how do you handle cache invalidation?
Physics is the problem here. Light in fibre travels at roughly two-thirds the speed of light, so a round trip between Mumbai and a server in Virginia costs about 200 ms before the server does any work. Add the multiple round trips of TCP and TLS and a page takes seconds to start. You cannot beat physics, but you can move the content closer to the user. That is exactly what a CDN, Content Delivery Network, does: a globally distributed network of edge servers (points of presence, PoPs) that cache and serve your content from a location near the user.
The basic flow. Your origin server is the source of truth. The CDN sits in front of it. A user in Pune requests a static file such as a JavaScript bundle. The request lands on a nearby edge server in Mumbai. If the file is in the edge cache (a cache hit), it is returned immediately in a few milliseconds. If not (a cache miss), the edge fetches it from the origin (or from a mid-tier regional cache to protect the origin), stores it according to caching rules, and returns it. The next thousand users in that region get hits. The hit ratio is the key metric, and a good CDN offloads 90 percent or more of traffic from your origin.
How does a user reach the nearest edge? Two main mechanisms. DNS-based routing: your domain has a CNAME to the CDN, and the CDN's authoritative DNS returns the IP of an edge chosen based on the resolver's location, health and load. Anycast: many edge servers around the world advertise the same IP address via BGP, and internet routing naturally delivers packets to the topologically closest one. Cloudflare uses anycast heavily; some CDNs combine both.
What is cached is controlled by HTTP headers from the origin: Cache-Control with max-age for browsers, s-maxage for shared caches such as CDNs, and directives like no-store, private and public; validators like ETag and Last-Modified allow revalidation and a 304 Not Modified response. The cache key is normally the URL plus selected headers or query strings (Vary). Static assets like images, CSS, JS and video segments are ideal; personalised or dynamic API responses generally are not, though CDNs can still speed those up by keeping warm TCP and TLS connections to the origin and terminating TLS near the user.
Cache invalidation is the famous hard part. Options are: TTL expiry (wait for it), explicit purge by URL, tag or wildcard (fast but API-limited and not instant everywhere), and versioned filenames (cache busting) where the build produces app.4f3a9c.js so every deploy gets a new URL and you can cache it for a year with immutable. Versioned URLs are the most reliable approach; the HTML entry point gets a short TTL or must-revalidate so it references the new bundle names. Stale-while-revalidate lets the edge serve an old copy while it fetches a fresh one in the background.
Beyond speed, CDNs give you DDoS absorption (attack traffic is spread over hundreds of PoPs), a web application firewall, TLS termination, image optimisation, bot management, and edge compute like Cloudflare Workers. Examples: CloudFront, Cloudflare, Akamai, Fastly. A related edge case: the client IP seen by your origin will be the CDN's, so you must read X-Forwarded-For or CF-Connecting-IP, and lock the origin down to only accept CDN traffic.
$ curl -sI https://static.example.com/app.4f3a9c.js
HTTP/2 200
cache-control: public, max-age=31536000, immutable
age: 8421
cf-cache-status: HIT
x-cache: Hit from cloudfront
via: 1.1 abc123.cloudfront.netage tells how many seconds the object has been in the edge cache; HIT confirms it was served without touching the origin.
CDN, Edge Caching, Anycast, Cache Invalidation, Latency