A network of servers spread around the world that serve your images, files, and static content from a location near each user.
Why it exists
Users far from your server wait longer for every image and file simply because of distance, and your origin strains under the repeated load. A CDN exists to keep copies of static content on servers around the world, so each user is served from somewhere nearby and your origin is spared.
How it actually works
Sending every image from one server in Dhaka to a user in London is slow. A CDN keeps copies of your static content (images, videos, scripts) on servers in many cities. Each user is served from the nearest one, cutting the distance and the wait.
It also absorbs huge traffic: a viral post's image load is spread across the CDN's global fleet instead of crushing your one server. Most of the heavy, unchanging content of a modern site is delivered this way.
A senior PM walks you through it
A junior PM, stuck
Marketing swapped the Eid banner image an hour ago. Dhaka users see the new one, but our overseas users still see the old banner. Engineering just said "CDN cache" and moved on. I have to tell marketing when the new banner actually goes live everywhere.
A CDN keeps copies of your images on servers in many cities, so each user is served from the nearest one instead of from Dhaka. That is why distant users can see a different version: they are hitting a different copy. Reading it is quick. Here are two responses for the very same image, one from our Dhaka origin and one from a Singapore edge, and two headers on the edge answer that tell you exactly why the old banner is stuck overseas.
GET /images/eid-banner.jpg from the Dhaka origin versus a Singapore edge
Served from the Dhaka origin
11.1
2
3200
4:
5:
6:890
Served from the Singapore edge
71.1
8
9200
10:
11:
12:42
13:3600
14:86400
Click a step to see the lines it points at.
Mistakes I've seen
Re-uploading the image again and again. The origin already has the new banner; the edges are serving old copies until max-age passes or you purge, so a fifth upload changes nothing.
Reading the delay as a slow deploy. Age and max-age show the edge is intentionally holding its copy; this is caching working as configured, not a stuck release.
Forgetting the purge step in a launch plan. A timed banner swap needs a CDN purge scheduled with it, or overseas users see the old creative for up to the full max-age window.
Setting max-age long on content you swap often. An 86400 max-age is fine for a logo and painful for a campaign banner; the freshness window is a decision, not a default to leave alone.
Tell marketing: "The new banner is live at our origin, but CDN edges abroad are serving an hour-old copy and are allowed to for up to a day. To flip it everywhere right now, eng needs to purge the CDN. For timed swaps we should schedule that purge with the launch." You read the edge headers and turned "CDN cache" into a plan with a time on it.
Where a PM meets this
"Images load slowly for overseas users" is often solved by a CDN, a config-and-cost decision more than a build.
CDNs cache content, so "I updated the image but the old one still shows" can be CDN caching, cleared by invalidation.
Hear it in a meeting
"Push the product images to the CDN, overseas load times will drop."