Content Delivery Networks (CDNs)

How a CDN Works

A CDN is a network of geographically distributed edge servers that cache your content. When a user requests a file, it's served from the nearest edge location instead of your origin server, dramatically reducing round-trip latency.

Push vs Pull CDNs

Pull CDNs fetch and cache content from your origin on first request, then serve cached copies afterward — simple to set up. Push CDNs have you proactively upload content to the CDN, giving more control at the cost of more operational overhead.

What Belongs on a CDN

Static assets (images, video, JS/CSS bundles) are the obvious fit. Increasingly, CDNs also cache API responses for read-heavy, rarely-changing data — worth mentioning if your design has that kind of traffic.

A good example to have ready: a product catalog page that changes a handful of times a day is a strong candidate for edge-caching the rendered response for a short TTL, even though it's dynamically generated — this can offload a large fraction of read traffic from your origin without any staleness a user would notice.

Cache Invalidation at the Edge

When content changes, you need to purge or version it at every edge location, not just the origin. Cache-busting via versioned file names (app.v2.js) sidesteps this entirely for static assets and is worth naming as the simpler alternative to active purging.

CDNs Reduce More Than Latency

Beyond speed, CDNs absorb traffic spikes and offer a first layer of defense against volumetric attacks, since malicious traffic gets filtered at the edge before it ever reaches your origin servers.

When a CDN Doesn't Help

Highly personalized, per-user dynamic content (a live account balance, a real-time notification feed) generally isn't a good CDN candidate, since there's little to no reuse across requests. Knowing where the boundary sits — and saying so — prevents you from over-applying caching to data that genuinely needs to be fresh.