A CDN (Content Delivery Network) is a network of cache servers spread around the world that keeps copies of your content close to users. Instead of every request travelling to your origin servers in one region, a user in Mumbai is served from a CDN server ("edge" or "point of presence", PoP) in or near Mumbai. Examples: Cloudflare, Akamai, Amazon CloudFront, Fastly.
In simple words
Instead of every customer in India ordering from one warehouse in the US, the company keeps copies of popular products in small local shops across India. You get your order from the shop down the road. That local shop is a CDN edge.
Most requests stop at the edge; only misses travel to the origin, and the answer is cached for the next user.
Why It Exists
Latency: light in fibre takes time; a round trip from India to a US data centre is on the order of 200+ ms. An edge a few milliseconds away removes most of that for cached content.
Offload: popular images, videos, JS and CSS are served by the CDN, so your origin handles a small fraction of the traffic and bandwidth.
Resilience: edges absorb traffic spikes and many DDoS attacks, and can keep serving cached content if the origin is briefly down.
How It Works
user (Mumbai) --DNS--> nearest edge (Mumbai PoP)
|
cache HIT? yes -> return the file (fast)
| no
v
fetch from origin (e.g. us-east) -> store at edge
(respecting Cache-Control / TTL) -> return to user
Next user near Mumbai asking for the same file -> HIT
Your domain (or an asset subdomain such as cdn.example.com) points at the CDN; DNS or anycast routing sends each user to a nearby edge.
The edge checks its cache. On a hit it responds immediately.
On a miss it fetches from your origin (a "pull" CDN), caches the response according to its headers (Cache-Control: max-age=...), and returns it.
Content leaves the cache when its TTL expires or when you purge (invalidate) it. Versioned filenames (app.3f9a1c.js) avoid most purging: a new version is simply a new URL.
Types
Pull CDN: fetches from the origin on first request. Easy; the first user in each region pays the miss.
Push CDN: you upload content to the CDN ahead of time. Good for large files you know will be requested (video segments, game patches).
Static vs dynamic: CDNs mainly cache static content, but they also accelerate dynamic requests (TLS terminated near the user, optimised routes back to the origin) and can run code at the edge.
When to Use It (and When Not)
Use for images, video, downloads, JS/CSS/fonts, and any public content read by many users in many places.
Be careful with personalised or private responses: cache keys must include what varies (or mark them private/no-store), or one user can be served another user's page.
Less useful for write-heavy APIs and content read once by one user.
Key Pointers
A CDN is a geographically distributed cache in front of your origin.
Cache hit ratio is the metric that matters: higher means lower latency and lower origin cost.
Control caching with HTTP headers; prefer versioned URLs over purges.
In a design with media (YouTube, Instagram), the CDN is what makes the bandwidth numbers possible.
Follow-up Questions
How does a user get routed to the nearest edge?
Either DNS-based routing (the CDN's DNS returns an edge IP near the resolver) or anycast (many edges announce the same IP and the internet's routing delivers packets to the nearest one). Many CDNs combine both.
You deployed a fix but users still see the old JS file. Why, and how do you avoid it?
The old file is cached at the edge (and in browsers) until its TTL expires. Put a content hash in the filename so each deploy references new URLs; keep long TTLs on the hashed files and a short TTL on the HTML that references them.
What is "origin shield"?
An extra caching layer between edges and your origin: edge misses go to one regional shield first, so the origin sees one request per object instead of one per edge.