Understanding CDNs (Content Delivery Networks)

I said I'd be writing about concepts I've frequently come across but never really stopped to properly understand. Today it's CDNs(Content Delivery Networks)

This one is interesting because it's not just something I've seen in everyday SPAs. I keep running it across tools and services I actually work with, and at some point I had to sit down and figure out what exactly is going on here.

So what is even a CDN?

At a high level, it's a system that makes sure your content gets to users faster, no matter where in the world they're requesting from.

Here's the version I had in my head before digging in:

It has something to do with caching. Data is being served from the edge of a network. Some technologies take advantage of CDNs to deliver their content faster

That's... not wrong. But it was pretty vague. Let me break it down properly.

The problem CDNs Solve

Let's say you deploy a web app and your server is sitting somewhere in the United States, Frankfurt, or wherever Vercel spins things up.

Now a user in Lagos, Nigeria opens your app.

Without a CDN, their request has to travel all the way from Lagos, across the Atlantic, to that server in the US, back across the Atlantic, back to Lagos. Every single time.

That round trip adds latency. And Latency is just the time it takes for data to travel from point A to point B and back again.

WITHOUT CDN

Now here's the part that really made me wonder, If it's all over the internet, why does distance matter?

It matters because the Internet is not magic. It runs on physical infrastructure: fiber optic cables, routers, submarine cables under the ocean, data centers. And even though signals travel as the speed of light through those cables, light still takes time to cross an ocean. Add in routers, the hops between networks, the processing at each stop and it all adds up.

Milliseconds, yes. But milliseconds matter when you're trying to build software that feels fast.

How a CDN fixes this

CDN providers have servers distributed all over the world, what are called edge servers. Instead of every request going back to your main server(the origin server),users get served from the closest edge server to them.

WITH CDN

Here's how it actually plays out. A user in Lagos, Nigeria requests your website. Instead of that request flying across the Atlantic, it hits an edge server somewhere nearby, If the provider has a presence in Lagos, It could be served right there. If not, the next closest option maybe somewhere else in West Africa. The point is it stays regional, not transatlantic.

If it's a cache hit, the content is already sitting on that edge server. It returns immediately. The origin server in the US doesn't even know the request happened.

If it's a cache miss, the edge server doesn't have it yet. It goes back to the origin, fetches the content, returns it to the user, and stores a copy so the next person requesting from that region gets it instantly.

That's the loop. Origin server holds the actual content. Edge servers hold cached copies and serve them to whoever is closest.

Worth noting here: What gets cached on edge servers is generic content, your HTML pages, images, JS bundles, stuff that looks the same for every user, User- Specific data like dashboards, auth states, or anything behind a login doesn't go through this path. That's a distinction CDNs and the developers configuring them are very deliberate about.

Each edge location serves the users closest to it. The origin only gets hit when and edge server needs to refresh its cache or sees content for the first time.

How this shows up in the tools we actually use

This is where it got relatable for me. CDNs aren't just a infrastructure concept. They are baked into services I use daily as a developer.

Cloudfare is probably the most obvious one. A huge part of what Cloudfare does is sit in front of your origin server and intercept requests. They have edge servers in cities all over the world, Lagos Included. When someone requests your site. Cloudfare serves cached content from the nearest location. Your origin doesn't really have to bother returning it.

Sanity is one I also noticed more recently. Sanity's main servers aren't in Nigeria, but when someone here requests content from sanity. It doesn't travel across the world. It comes from Sanity's CDN edge server, which is much closer. although sanity even does something interesting by exposing a flag know as useCDN:true/false, As an engineer I can either opt to fetch content straight from the origin or edge, Cool right?

Vercel and Netlify(popular host providers) have this built in too. When you deploy a static site or use edge functions, you're not really deploying to one server. You're deploying to their edge network. That's partly why deploys feels like magic; your content is already near you before the first request even lands.

As a developer, what does this actually mean for you?

Now that I have a better mental model of how this works, a few things I've run into as an engineer started clicking:

Cache invalidation is a real thing. When I update content, edge servers might still be serving the old cached version. Some platforms handle this automatically on deploy, others require explicitly purging the cache. I've pushed updates using a Content management system and wondered why users were still seeing the old version. Turns out the edge servers just hadn't caught up yet.

Another thing worth understanding is Cache-Control headers. The server can include instructions on how long content should be cached when it sends a response. For content that changes often, short cache times or none at all. For static assets like images, fonts, and JS bundles, cache aggressively. Getting this right means the CDN works with the app, not against it.

And not everything should be cached, this one is easy to miss. User-specific data, auth responses, anything that varies per person. None of that should be sitting on and edge server. CDNs shine brightest with static assets and content that looks the same regardless of who is asking for it.

Wrapping Up

CDNs exist because the internet, while fast, is still physical and distance adds latency. Instead of every user talking to one origin server far away, CDNs distribute copies of your content across edge servers worldwide so users get it from somewhere close to them.

You're almost certainly using a CDN if you're deploying on modern infrastructure. But understanding how it works helps you make smarter decisions about caching, about content structure, about why your users in one region are having a different experience than users somewhere else.

Let me know if you add have anything to add in the comments or any push back, would love to discuss it. And when I find something else I use every day but never really understood, I'll be back. Soon. Very soon. Byeeeeee