systemsMarch 21, 20263 min read

CDNs: Why Your Users Shouldn't Have to Talk to Your Origin

What a CDN is, how it reduces latency for global users, and when adding one actually helps versus when it's just another thing to operate.

CDNs: Why Your Users Shouldn't Have to Talk to Your Origin

What Is a CDN?

A Content Delivery Network (CDN) is a globally distributed network of servers — called edge nodes — that cache copies of your content close to where your users are.

A user in Singapore requesting your image shouldn't wait for it to travel from a US data center. The CDN puts a copy of that image on a server in Singapore. The request never reaches your origin.


The Problem It Solves

Two things get worse as distance increases: latency and bandwidth cost.

Every millisecond of network round-trip adds up. A 200ms round-trip from Singapore to Virginia is just physics — the signal has to travel ~15,000 km. A CDN node in Singapore answers in 5ms.

It also protects your origin server. If 10 million users want the same image, your origin shouldn't serve it 10 million times. The CDN serves it once, caches it, and handles the rest.


How It Works

The first request for a file hits the CDN edge. If it's not cached there, the edge fetches it from your origin, caches it, and serves it — this is called a cache miss. Every subsequent request for that file from the same region is served from the cache — a cache hit. No origin involved.

Cache lifetime is controlled by Cache-Control headers you set on your origin. Cache-Control: max-age=86400 means the CDN caches it for 24 hours before re-fetching.


When to Add It

Add a CDN when:

  • You have global users — any geography significantly different from your origin region
  • You serve static assets — images, JavaScript, CSS, fonts, videos
  • You want to reduce load on your origin server
  • You're building a site where page load speed directly affects conversion or user retention

Rule of thumb

If your app has a frontend with images and JS bundles, a CDN is not optional for global users. It's table stakes.

When NOT to Add It

  • Purely API-driven backends with no static assets
  • Highly personalized responses that change per user — you can't cache GET /user/me
  • Internal tools used by 50 people in the same office

Warning

Trying to cache dynamic, user-specific API responses through a CDN is a trap. You'll either serve stale data to the wrong users or your cache hit rate will be 0% and you've added latency for nothing.

Cache Invalidation — the Gotcha

CDNs are great until you need to update a cached file. If you push a new app.js but your CDN has cached the old one for 24 hours, users get the old version.

The solution: cache-busting via content hashing. Modern bundlers (Webpack, Vite) name files like app.a3f9b2.js. When the file changes, the name changes. The CDN sees a new URL — instant cache miss.

Common mistake

Setting long TTLs on HTML files. Your index.html references app.a3f9b2.js — if the HTML is cached for a week, users don't get the new JS file. Keep HTML TTLs short (minutes) and asset TTLs long (days/weeks).

Real World

Cloudflare, AWS CloudFront, and Fastly are the big names. Cloudflare is free for basic use and one of the most used CDNs on the internet. Netflix built their own CDN (Open Connect) because commercial CDNs couldn't handle the volume they needed.


Takeaways

  • A CDN puts copies of your content close to users, reducing latency and origin load
  • Ideal for static assets and global audiences
  • Cache invalidation is the hardest part — use content-hashed filenames
  • Don't use it for dynamic, user-specific responses
  • If your users are all in one geography and your origin is there too, a CDN adds little value
Share