Q21 — Why do CDNs exist — and what can they not solve?

What is the fundamental physical constraint?

Light travels through fiber optic cables at roughly 200,000 km/s — about two-thirds the speed of light in a vacuum. This sounds fast, but at the scale of geography, it's a real constraint.

The distance from New York to London is ~5,500 km. Light (and therefore your TCP packet) takes at minimum 27 milliseconds to make that one-way journey. A round trip (request + response) cannot be faster than 54ms, no matter how powerful your server is, no matter how optimized your code is. Physics is the ceiling.

In practice, with routing, switching, and protocol overhead, a New York–London round trip is 80–100ms. A US–Singapore round trip is 200–250ms. A US–Australia round trip can exceed 300ms.

Now consider TLS handshakes (2 round trips before HTTP/2, 1 with TLS 1.3), TCP slow start, and the fact that loading a webpage requires multiple round trips. A user in Singapore visiting a server in New York might easily experience 1–2 seconds of latency just from physics — before any of your application code runs.

This is the problem CDNs exist to solve.

What does a CDN actually do?

A CDN (Content Delivery Network) is a geographically distributed network of servers — called Points of Presence (PoPs) or edge nodes — positioned close to end users around the world. A large CDN like Cloudflare has PoPs in over 200 cities. Fastly, Akamai, and AWS CloudFront have similar coverage.

When a user in Singapore requests a resource from your application, instead of that request traveling to your origin server in New York, it goes to the nearest CDN edge node — perhaps in Singapore itself, or in nearby Kuala Lumpur. The edge node checks if it has the response cached. If it does, it responds immediately — from a server 10–50ms away instead of 250ms away.

If the edge node doesn't have the content cached (a cache miss at the edge), it fetches it from your origin server, caches it locally, and serves the response. Future requests from users in that region hit the cache, not your origin.

The result: the expensive cross-ocean round trip is paid only on the first request from a region. Subsequent requests are served at the speed of local geography.

Why is this different from application-level caching?

Application-level caching (Redis, Memcached) reduces the time your server spends computing a response. The response still has to travel from your server to the user, paying the full geographic latency.

CDN caching reduces the geographic distance the response travels. The computation may have happened on your origin server, but the bytes are now stored close to where users actually are. CDNs don't make your server faster — they make the data delivery faster by eliminating distance.

These two techniques are complementary and both are often used together.

What do CDNs cache?

CDNs are most effective for content that is the same for every user — static assets, primarily:

Static files like JavaScript bundles, CSS stylesheets, fonts, and images are perfect CDN candidates. They don't change per user, they don't change frequently, and they're often large. Serving a 500KB JS bundle from a local edge node instead of New York is a dramatic latency improvement.

Videos and media are the highest-value CDN use case. A 4K video is gigabytes of data. Delivering it from a local CDN edge node at local network speeds instead of streaming across oceans is the difference between smooth playback and constant buffering. Netflix, YouTube, and Twitch all rely entirely on CDN infrastructure for video delivery.

API responses that are identical for many users and not personalized — public data like exchange rates, weather, sports scores, or product catalogs — can also be cached at the CDN edge, dramatically reducing origin load and latency.

What can CDNs not solve?

Understanding the limits is as important as understanding the benefits.

Personalized or dynamic content. A CDN can only cache a response if the response is the same for all users requesting that URL. The moment a response contains anything user-specific — user's name in the header, their cart contents, their personalized feed, their authentication state — the CDN cannot cache it. A GET /dashboard that returns different HTML for every logged-in user cannot be CDN-cached. These requests must still hit your origin server, paying full geographic latency.

Mutations — POST, PUT, DELETE. CDNs sit in front of GET requests for cacheable content. Write operations must reach your origin. A user submitting a form, placing an order, or sending a message goes to your origin server no matter where they are.

A slow origin. The CDN only helps when requests hit the edge cache. On a cache miss — the first request from a new region, or any uncacheable request — the response must come from your origin. If your origin is slow (slow database queries, expensive computation, high load), the CDN miss is slow, and users in distant regions experience slow + distant. CDNs cannot fix a slow backend, they can only hide it behind a cache.

Real-time data. If your data changes every second — live sports scores, live auction prices, live chat — the CDN cache is stale by the time it's served. Aggressive cache invalidation is possible (most CDNs have APIs to purge specific URLs), but invalidating cache entries across hundreds of PoPs around the world takes seconds. For truly real-time data, the CDN adds latency complexity without adding cache benefit.

Origin unavailability. If your origin server goes down, CDN cache misses have nowhere to go. CDNs can serve stale content in this case (with stale-if-error directives), which is better than errors, but cached content goes stale and new content cannot be served.

What else do CDNs provide beyond caching?

Modern CDNs have expanded well beyond simple static file caching:

DDoS protection and traffic scrubbing: CDN edge nodes absorb volumetric attacks (hundreds of gigabits per second of flood traffic) distributed across their global network. Your origin never sees the attack. Cloudflare, for example, has bandwidth capacity measured in tens of terabits per second — dwarfing most attack volumes.

TLS termination at the edge: The user's TLS handshake is completed at the nearest CDN edge node — adding only local latency, not cross-ocean latency. The CDN then communicates with your origin over a persistent, pre-warmed connection, often using HTTP/2 or HTTP/3. This can reduce perceived TLS handshake overhead dramatically for distant users.

Edge compute: CDNs like Cloudflare Workers and Fastly Compute@Edge allow you to run code at the edge node — modifying requests, personalizing responses, running A/B tests, authenticating users — all without hitting your origin. This is the frontier of where CDNs are going.

The mental model

Problem: physics — light travel time creates irreducible latency across geography
         Users far from your origin always wait, no matter how fast your server is

CDN solution: cache content close to users, distributed globally
  User in Singapore → nearest CDN edge (50ms away) instead of origin in New York (250ms)
  Edge hit: served at local speed, origin not involved
  Edge miss: fetch from origin once, cache it, serve all future requests from edge

CDN accelerates: static assets, media, public API responses
                 anything the same for all users

CDN does NOT help with:
  ├── Personalized content (user-specific responses can't be cached)
  ├── Write operations (must reach origin)
  ├── A slow origin (misses still hit the slow backend)
  ├── Real-time data (cache goes stale immediately)
  └── Origin downtime (misses have nowhere to go)

CDNs also provide: DDoS absorption, TLS at edge, edge compute

CDNs exist because no amount of application optimization overcomes the speed of light. Once your server is fast, the next bottleneck is the distance between your server and your users. CDNs solve that one problem extremely well — and only that problem.