CDN vs Application Cache: How Content Delivery Networks Work

A content delivery network (CDN) is a globally distributed network of caching servers (edge locations or points of presence, PoPs) that serve content from close to users. Instead of every request crossing an ocean to your origin, most are answered from a server a few milliseconds away. CDNs cut latency, absorb traffic spikes and attacks, and dramatically reduce load and bandwidth at the origin. The key architectural decision is what belongs at the CDN and what belongs in the application cache behind it.

The problem a CDN solves

A news site keeps its videos in a New York data center. A user in Tokyo presses play, and the request travels about 11,000 km to New York and back: some 200 ms of network latency alone, and the video stutters. Then a clip goes viral: millions watch it, the origin takes 10,000 requests a second, bandwidth bills spike, and some requests time out.

That latency is physics, not engineering: no server tuning removes the speed-of-light delay across the Pacific. A CDN fixes it by keeping cached copies at the network edge, near users. Tokyo viewers fetch the video from a Tokyo edge server in a few milliseconds, and the origin handles a fraction of the traffic because the edges absorb most of it.

How a CDN works

You publish static files through the CDN, which replicates them to edge servers in major cities across continents: Los Angeles, London, Tokyo, Sydney and hundreds more. Users are routed to the nearest edge by DNS or anycast (many edges share one IP and the network routes to the closest).

A London user requests https://cdn.example.com/logo.png and DNS sends them to the London edge. On a cache hit, the edge already has the file and returns it in about 5 ms. On a cache miss, it fetches the file from the origin (about 200 ms), stores it, and serves it; every later London user gets a hit. Requests start cold (every edge cache empty) and the edge hit rate climbs as popular files are cached; that hit rate is what determines how much traffic still reaches your origin.

Files are cached for their TTL: perhaps 24 hours for a logo that rarely changes, 5 minutes for frequently updated content. After it expires, the edge fetches a fresh copy. CDNs cut latency through proximity, cut origin load by serving cached copies, and improve availability by spreading traffic over many servers.

What CDNs handle well

CDNs cache at the HTTP level: they store complete responses (headers and body) keyed mainly by URL, plus the host and any headers named in Vary. That fits content that is:

• Public and identical for everyone: a product image, a JavaScript bundle, a marketing page. Every user gets the same bytes, so each edge keeps one copy for all nearby users.
• Rarely changing: a CSS file changes on deploy, not between requests, so it can be cached for days or weeks. When it changes, deploy it under a new, content-hashed file name (app.3f9a1c.js), so the old copy is never stale: it's simply never requested again. Use long TTLs (a year) and immutable.
• Tolerant of staleness: a blog post cached for 5 minutes means a typo fix takes 5 minutes to reach everyone, which is fine for most static content.

So CDNs are the right choice for images, video, fonts, compiled assets, downloads (installers, game patches), documentation and pre-rendered pages: anything where the response is the same no matter who asks.

Where CDNs fall short

• Personalized responses. A feed, a cart or a notification count differs per user. Caching it at the edge means either serving everyone the same generic response (losing personalization) or storing billions of per-user entries at every edge (impractical).
• High-cardinality keys. A search API with millions of possible queries gets a poor hit rate at any single edge: the Tokyo edge may see each unique query only once.
• Consistency-sensitive data. Inventory counts, auction bids and balances must be accurate in real time. Even a 5-second edge TTL can let a customer buy something that has already sold out.

For these, use the application cache instead: it sits behind the CDN, near the application servers, and caches at the data level.

Application cache: data-level caching

An application cache (Redis, Memcached) stores individual data objects, such as a user record, a product's metadata or a computed feed, not whole HTTP responses. That distinction matters: an HTTP-cached page ties the cache key to one URL, while a cached object can be assembled into any response. The same cached user profile serves the profile page, the settings page and the activity feed, and one invalidation updates all three.

Application caching covers what CDNs can't: per-user data, complex aggregations and computed results that don't map cleanly to one URL.

Origin shielding

On a miss, an edge fetches from the origin. With 200 edge servers worldwide, a popular page that expires at all of them at once sends 200 requests to your origin at the same moment, and across thousands of URLs that becomes a constant barrage.

Origin shielding adds a cache tier between the edges and the origin. Instead of each edge fetching from the origin, edges go through a designated shield PoP (or a few). The shield either has the object cached or fetches it from the origin once. The origin sees roughly one request per object per shield instead of one per edge, which matters most when caches expire or traffic spikes and many edges discover at once that their copy is stale.

Most CDNs offer shielding as a setting. Mention it in interviews about high-traffic systems: it shows you know the thundering herd problem exists at the edge too.

Deciding what goes where

"Yes" for the CDN assumes the response is public and identical for everyone; personalized or login-gated responses usually bypass the CDN (or need careful cache-key variation) even when the data looks static. For most systems the split is simple: CDN for static assets and public pages, application cache for everything else. The interesting case is the hybrid fragment approach: a product page's static layout shell is CDN-cached for hours, while personalized pieces (price, stock, recommendations) are fetched separately from the application cache and refresh every few seconds, each part expiring on its own schedule.

Controlling the cache

Pull vs push

• Pull CDN (most common): edges fetch from your origin on the first miss and cache it. Zero upfront work; the first user in each region pays the miss.
• Push CDN: you upload content to the CDN's storage ahead of time. Good for large files you know will be popular, like a game release.

Video streaming

Streaming services encode each video into several qualities and cut them into segments of 2–6 seconds (HLS or DASH). Players request segments over HTTP, switching quality with bandwidth (adaptive bitrate). Because segments are just cacheable files, CDNs can serve enormous audiences: the origin barely sees the traffic of a popular stream. See video streaming.

Beyond caching

• DDoS protection and a WAF: the CDN's huge capacity absorbs volumetric attacks before they reach you.
• TLS termination near users saves round trips on the handshake. See HTTP versions.
• Edge compute (Cloudflare Workers, Lambda@Edge, Fastly Compute) runs small functions at the edge for redirects, A/B tests, authentication or personalization.

Common CDNs