CDN (Content Delivery Network)
A CDN caches content on edge servers close to users, cutting latency from hundreds of milliseconds to tens, absorbing traffic spikes, and shielding origin servers. Cloudflare, CloudFront, Akamai, and Fastly are the canonical providers.
Edge Caching and Why It Works
The speed of light is the constraint: a round trip from Sydney to a us-east origin is roughly 200 ms before the server does any work, and TLS setup multiplies that by several round trips. A CDN places points of presence (PoPs) in hundreds of cities, Cloudflare operates in 300+, so the user's TCP and TLS handshakes terminate perhaps 10-30 ms away. Cached content is served entirely from the edge; even uncached requests benefit because the edge maintains warm, long-lived connections to the origin over optimized routes.
A request flow: user hits static.example.com, GeoDNS or anycast lands them on the nearest PoP, the edge checks its cache, on a hit it serves immediately, on a miss it fetches from the origin (or from a regional shield cache in tiered architectures), stores the response per its cache headers, and serves it. Subsequent users in that region get hits. Cache hit ratios of 90-99 percent are normal for static assets, meaning the origin sees 1-10 percent of raw traffic.
CDNs also provide origin shielding against traffic spikes and DDoS: a viral link or an attack is absorbed across hundreds of PoPs instead of concentrating on your servers. Request collapsing (coalescing many concurrent misses for the same object into one origin fetch) prevents thundering herds when a hot object expires.
Push vs Pull CDNs
A pull (origin-pull) CDN populates its cache lazily: the first request for an object misses, the edge fetches it from the origin, then caches it. This is the default model for CloudFront, Cloudflare, and Fastly. It is nearly zero-maintenance, you just set cache headers, and storage is used only for content that is actually requested. The downsides are first-request latency in each region and origin dependence on misses.
A push CDN requires you to upload content to the CDN's storage proactively, before any user requests it. This suits large, infrequently changing files with predictable demand, video releases, game patches, software installers, where you cannot afford a miss storm at launch. Netflix takes this to the extreme with Open Connect: it pre-positions popular titles onto appliances inside ISP networks during off-peak hours, so a new season is already sitting near viewers at release.
Most web workloads use pull because content popularity follows a long tail and pushing everything everywhere wastes storage. A hybrid is common: pull for the general case, plus cache warming (scripted pre-fetching of known-hot URLs) before big events.
TTLs and Cache Invalidation
Cache lifetime is controlled by HTTP headers: Cache-Control max-age governs browser caching and s-maxage governs shared caches like CDNs. The cleanest strategy is immutable, fingerprinted assets: build tools emit app.a1b2c3.js, you set Cache-Control public, max-age=31536000, immutable, and you never invalidate, deploying new HTML that references new filenames instead. Invalidation becomes a non-problem for the bulk of your bytes.
For content that changes in place (HTML pages, JSON APIs, images at stable URLs), you need active invalidation: purge APIs that remove objects from edge caches. Fastly executes purges globally in well under a second and supports surrogate keys, tags attached to responses so you can purge everything tagged product-123 when that product changes. CloudFront invalidations are slower (tens of seconds to minutes) and priced per path, which pushes teams toward versioned URLs.
A powerful middle ground is stale-while-revalidate: serve the cached copy immediately while refreshing it in the background, so users never wait on origin latency, plus stale-if-error to keep serving stale content when the origin is down. The classic quip that cache invalidation is one of the two hard problems in computer science is worth taking seriously: prefer designs (fingerprinting, short TTLs plus SWR) that make correctness not depend on perfect purging.
Dynamic Content and Edge Compute
CDNs are not only for static files. Dynamic content acceleration routes uncached API and HTML traffic through the CDN anyway: the user's TLS handshake happens at the nearby edge, and the edge relays the request to the origin over pre-warmed, congestion-tuned connections on optimized backbone routes. This alone can cut 30-50 percent off dynamic request latency for far-away users, which is why sites put their entire domain behind Cloudflare or CloudFront, not just /static.
Edge compute goes further, running code in the PoP: Cloudflare Workers, CloudFront Functions and Lambda@Edge, and Fastly Compute handle authentication token checks, A/B test assignment, redirects, personalization, and API response stitching without a round trip to the origin. Cloudflare Workers cold-start in under 5 ms using V8 isolates, making per-request edge logic practical.
Be ready to say what should not be CDN-cached: private, per-user responses (unless keyed carefully with Vary or cache keys including auth state), and anything where serving a stale answer is dangerous. A classic incident pattern is accidentally caching a Set-Cookie response and serving one user's session to others, so mention explicitly stripping cookies and setting Cache-Control private on personalized responses.
Key points
- ▸Edge PoPs cut round-trip latency from 100-300 ms to 10-30 ms and terminate TLS close to users; hit ratios of 90-99 percent shield the origin.
- ▸Pull CDNs populate lazily and suit long-tail web content; push CDNs pre-position large predictable content, exemplified by Netflix Open Connect.
- ▸Fingerprinted immutable assets with max-age=31536000 sidestep invalidation entirely; purge APIs and surrogate keys handle content that changes in place.
- ▸stale-while-revalidate and stale-if-error hide origin latency and origin outages from users.
- ▸CDNs accelerate dynamic traffic too, via TLS at the edge, warm origin connections, and optimized routing; edge compute runs logic in the PoP.
- ▸Never cache personalized responses carelessly; cookie-caching incidents that leak one user's data to another are a classic failure mode.
Tradeoffs
Pull CDN
Pros
- + Near-zero operational effort; cache fills based on real demand
- + Storage-efficient for long-tail content
Cons
- − First request per region is slow (miss penalty)
- − Origin must absorb miss traffic, including synchronized misses on expiry without request collapsing
Push CDN
Pros
- + No miss storms at launch; content is pre-positioned for predictable spikes
- + Origin can be minimal or offline at serve time
Cons
- − You manage uploads, versioning, and deletion yourself
- − Wasteful for content with unpredictable or long-tail demand
Long TTL with purge vs short TTL
Pros
- + Long TTLs maximize hit ratio and minimize origin load
- + Purge APIs and surrogate keys give precise, fast invalidation on providers like Fastly
Cons
- − Purge is an extra operational dependency that can fail or lag
- − Short TTLs are simpler and self-healing but raise origin traffic and tail latency
In the interview
- ★Add a CDN the moment the problem mentions global users, media, or read-heavy traffic, and quantify the win: 200 ms cross-ocean round trips become 20 ms.
- ★State your invalidation strategy unprompted, fingerprinted immutable assets for static, surrogate-key purge or short TTL plus stale-while-revalidate for mutable content.
- ★For a video or feed-heavy design, discuss push vs pull and cite Netflix Open Connect as the push extreme.
- ★Mention what you will not cache (per-user authenticated responses) and how you prevent cookie-leak caching bugs.