CDN
Content Delivery Network. A geographically distributed network of edge servers that caches content close to end users, reducing origin server load and cutting time-to-first-byte by 50–200ms depending on user location.
The Problem CDNs Solve
Physics sets the floor on latency: light travels ~200km/ms in fibre. A user in Tokyo hitting an origin server in Virginia adds ~150ms of round-trip time before a single byte is served. A CDN places cached copies of your content at edge Points of Presence (PoPs), spanning 50–300 locations globally, so that request goes to a node ~20ms away instead.
The latency improvement is the secondary benefit. The primary one is origin offload: a well-configured CDN absorbs 80–99% of read traffic so your origin never sees it.
Push vs Pull CDN
Pull CDN (most common): On the first request for an asset, the edge node fetches it from origin, caches it, and serves it. Subsequent requests are cache hits. TTL controls how long the cached copy lives. Cloudflare, Fastly, and CloudFront operate in pull mode by default.
Push CDN: You explicitly upload content to the CDN's storage. No origin fetch ever occurs. Better for large files (videos, software downloads) where you know the content upfront and can't afford the first-request miss latency. Akamai and MaxCDN support push mode.
Cache Invalidation at the Edge
Edge cache invalidation is the operational headache nobody talks about in design interviews. Your TTL is the primary control. Set it too long and users see stale content; too short and your cache hit ratio collapses and origin load rises.
For content that changes unpredictably, use cache busting: embed a hash or version in the asset URL (/app.a3f9b2.js). When the file changes, the URL changes, so there's no stale cache to invalidate. The new URL is a cold miss everywhere.
For content that changes on a schedule, use surrogate keys (supported by Fastly and Varnish): tag cache entries with logical keys and purge by tag rather than URL. A single API call invalidates all cached variants of a product page across all edge nodes.
Origin Shield
Without an origin shield, a cache miss from 50 edge nodes all fires simultaneously back to origin: 50 concurrent requests for the same uncached object. Origin shield adds a centralised caching layer between the edges and your origin. Cache misses from all edges converge on the shield, which makes a single request to origin. This collapses 50 concurrent origin requests into one.
When CDN Doesn't Help
CDNs are designed for cacheable content. They don't help, and can add latency, for:
- Personalised responses that vary per user (unless you use edge computing)
- API calls that require real-time data
- WebSocket connections (though some CDNs now proxy these)
- Very low TTL content where cache hit ratio approaches zero
Interview Tip
The CDN question interviewers actually ask isn't "what is a CDN." It's "how would you serve 500M users globally with P99 TTFB under 100ms?" The expected answer involves CDN for static assets, origin shield to protect the backend, and cache-busting for versioned assets. Candidates who mention the cache hit ratio calculation (hit ratio = cache hits / total requests) and its relationship to origin cost demonstrate production awareness.
Related Concepts
A distributed hashing scheme that minimizes key remapping when nodes are added or removed.
Distributes incoming traffic across multiple servers to prevent any single node from becoming a bottleneck. The mechanism that makes horizontal scaling functional in practice.
Object storage for unstructured binary data: images, videos, documents, ML model weights. Designed for durability and throughput at scale, not low-latency random access.