CDN Engineering Insights

They overlap at the edge of a system, but their primary jobs are different.

A CDN is best understood as a globally distributed, managed reverse proxy — the core mechanism is the same, the scope is different.

A reverse proxy (NGINX, Varnish, Envoy) sits in front of an origin, forwarding and optionally caching requests — usually in one region or inside the origin's own infrastructure. A CDN takes that same reverse-proxy-and-cache mechanism and distributes it across many geographically dispersed edge locations, adding global request steering, DDoS absorption, and origin protection at much larger scale. For the local/origin-side role, see Reverse Proxy fundamentals.

The line between "cacheable" and "not cacheable" is rarely as sharp as it first appears — the real skill is finding cacheable slices inside dynamic responses.

A naive view treats content as strictly static (cache forever) or strictly dynamic (never cache). In practice, most high-traffic systems find a middle ground: a personalized page can still have a static shell cached at the edge with a dynamic fragment loaded client-side; a "real-time" leaderboard can tolerate a 5-second-stale cached version for most read traffic (the 5 s and 99% figures here are illustrative, not measurements).

Illustrative origin-load example for that leaderboard: assume 20,000 read requests/s. The hit ratio is a planning figure, not a guarantee, but compare the outcomes: at 95% the origin sees 20,000 × 0.05 = 1,000 req/s; at 99% it sees 20,000 × 0.01 = 200 req/s, five times less, from what looks like a small improvement.

Invalidation and versioned URLs solve the same underlying problem — "how do users get new content" — with very different operational costs.

Treating origin protection as a first-class design goal — not just a side effect of caching — changes how you configure a CDN.

If the only goal is latency, you might accept a lower cache-hit ratio in exchange for fresher content. If origin protection is an explicit goal, you deliberately push toward higher hit ratios (micro-caching dynamic content, origin shielding, request collapsing) even at the cost of a few extra seconds of staleness — because the alternative is an origin that can't survive its own traffic.

The newest evolution of CDN infrastructure: running actual application logic at the edge, not just caching static responses.

Edge functions let you run small pieces of code (request rewriting, A/B test assignment, authentication checks, even full server-side rendering) at the same distributed locations that used to only cache files. This pushes compute physically closer to users the same way caching pushed content closer — reducing origin round trips for logic that doesn't need the full backend stack.

The mistakes that repeatedly appear once a CDN is running in front of real traffic.

Fast answers to the questions that come up most often.

A composite view of how CDN, load balancer, and origin typically fit together in production.

A typical large-scale web architecture layers these systems: the CDN handles the outermost tier, absorbing static assets and increasingly some cacheable dynamic responses; requests that must reach the origin usually pass through a load balancer, reverse proxy, or both before reaching an application server fleet; those servers then talk to databases, caches, and other backend services.