CDN as Infrastructure

The topology is short. A user resolves the hostname to the nearest edge location. If the edge holds a fresh copy of the object, it answers directly and your infrastructure learns nothing about the request. If it does not, the edge fetches from the origin — object storage for static assets, a load balancer for dynamic responses — caches it according to the response headers, and serves it. Every subsequent request in that region is served locally.

The latency argument is the obvious one and it is mostly about round trips rather than bandwidth: a TLS handshake to an edge 20 ms away beats the same handshake to an origin 250 ms away, and a page that fetches thirty assets pays that difference thirty times over. The Networking domain covers why. What matters from the infrastructure side is the second and third effects.

The second is offload. A high cache-hit ratio means most requests never reach the origin, so the origin is sized for the misses rather than for the traffic. That changes autoscaling behaviour, changes the egress bill, and provides genuine protection during a traffic spike — a link that goes viral is absorbed by the edge instead of by your fleet. The third is origin protection: once everything arrives through the edge, the origin can be locked down so that only the edge may reach it, which converts a public bucket or a public load balancer into a private one.

Cacheability is decided by the response, and the decision is entirely yours. Static assets with content-hashed filenames are the easy case: the filename changes whenever the content does, so they can be cached effectively forever and a deploy invalidates nothing — it simply publishes new names. This is the pattern worth designing toward, because it removes the invalidation problem instead of managing it.

The dangerous case is a per-user response cached as if it were public. A response containing one customer's data, served from an edge to the next visitor, is a data-exposure incident caused by a caching header. The rules that prevent it are mechanical: anything behind authentication is private, no-store unless you have explicitly reasoned otherwise, the cache key must include every input the response varies on, and cookies and authorization headers must be excluded from being cached, not merely forwarded.

Invalidation is the other operational reality. A purge is not instant and not free — providers rate-limit or charge for it, and it propagates across a global network over seconds to minutes. Designing so that purges are rare, by versioning URLs rather than overwriting them, is worth more than any purge tooling. See CDN Architecture in the Architecture domain for the strategy side.

A CDN is one of the few components in this domain that frequently *reduces* total spend rather than adding to it. The reason is that edge delivery is usually cheaper per gigabyte than origin egress, and every cache hit removes a gigabyte from the more expensive meter entirely. At a high hit ratio the origin serves a small fraction of the bytes, and the saving on origin egress commonly exceeds the CDN's own charges.

The compute saving is real too and less visible. Requests served at the edge do not reach the load balancer, do not occupy an application thread and do not count toward the metric your autoscaler watches — so the fleet is smaller. The offload also flattens spikes, which means less scaling churn and less over-provisioned headroom.

The line item that surprises people is invalidation, along with per-request charges in regions with different rates and the cost of edge functions if you run logic there. And the cost that is not money: an aggressively cached asset served with a wrong header is served wrongly everywhere at once, which is a much larger blast radius than a bad response from one origin. See Egress: Moving Data Costs Money, Not Just Storing It.