Content Delivery Networks (CDNs)
Physical distance is a latency floor no server capacity fixes — a CDN's whole job is shrinking that distance.
Beginner
TopNotchNote
Notes that matter
the problem: physical distance is a latency floor no amount of server capacity fixes
A restaurant's menu photo, served from a single origin datacenter on the US East Coast, takes noticeably longer to reach a customer in Singapore than one in New York — not because the server is slow, but because light (and therefore data) takes real time to cross real distance. No amount of scaling the origin server fixes that; the fix has to bring the content physically closer to the user.
what a CDN is
A content delivery network is a set of geographically distributed proxy servers ("edge" servers) that cache content close to end users. A request for PlateRoute's restaurant photos gets served from a nearby edge location instead of crossing the globe to the origin server every time.
| What a CDN reduces | How |
|---|---|
| Latency | Physical distance to the serving server shrinks from continent-spanning to regional. |
| Origin load | One edge server can serve the same cached photo to thousands of nearby users without ever asking the origin again. |
| Bandwidth cost | The origin sends the file to each region's edge once, not once per end user in that region. |
what a CDN typically caches
CDNs are built around static content — files that don't change per request: images, videos, CSS/JS bundles, restaurant menu photos. Dynamic content that's personalized per user (an individual's live order status) generally isn't a good fit for edge caching, since caching it wouldn't help — the next request needs fresh, user-specific data anyway.
push vs. pull CDN models
| Model | How content gets to the edge | Trade-off |
|---|---|---|
| Pull (on-demand) | The edge server fetches content from the origin on the first request for it (a cache miss), then serves cached copies to subsequent requests. | Simple to operate — new content is automatically available without a manual push step, but the very first request in each region pays full origin latency. |
| Push | The origin proactively uploads content to edge locations ahead of time. | Every user gets edge-speed delivery immediately, but requires knowing in advance what to distribute and where — more operational overhead. |
Most CDNs default to pull for the long tail of content and offer push for high-value assets a business wants pre-warmed everywhere (a major promotional banner going live at a specific time, for instance).
core components
| Component | Role |
|---|---|
| Routing system | Directs each client to its nearest healthy edge location, informed by client geography and real-time load/health data. |
| Edge (proxy) servers | Serve cached content from RAM/SSD; the actual point of contact for end users. |
| Distribution system | Propagates content from the origin out to edge servers. |
| Origin servers | The authoritative source for content the edge doesn't have cached. |
| Scrubber servers | Filter malicious traffic (e.g. during a DDoS attack) before it reaches the origin. |
cache invalidation: the hard part
Every edge cache eventually faces the same question a distributed application cache does: what happens when the origin content changes? A restaurant updates its menu photo, but edge servers around the world are still serving the old one. The standard fix is a time-to-live (TTL) per asset, after which the edge re-validates with the origin — plus an explicit invalidation/purge API for cases that can't wait out the TTL, like taking down content for a policy violation immediately.