Content Delivery Networks

Overview

A content delivery network (CDN) is a geographically distributed set of edge servers that cache content close to users so requests are served from a nearby location instead of the distant origin server. By shortening the network path, a CDN cuts latency, absorbs traffic that would otherwise hit the origin, and improves availability during spikes.

🧠 Mental model: A CDN is like a chain of local newspaper stands. Instead of everyone driving to the printing press (origin server), each neighborhood has its own stand (edge server) stocked with today's papers.

Key Concepts

A CDN places edge servers, often called points of presence, in many regions. A user request is routed to the nearest edge; on an edge cache hit the content is returned immediately, and on a miss the edge fetches from the origin, caches the result, and serves it. This is the same caching idea from caching strategies applied at the network edge rather than inside one data center.

Pull-based model

The origin holds the content and the CDN pulls it lazily. The first request for an asset at a given edge misses and is fetched from the origin; subsequent requests are served from the edge until the cached copy expires by its time-to-live (TTL). It requires little setup because you simply point the CDN at the origin, but the first user at each edge pays the miss penalty.

Push-based model

You proactively upload (push) content to the CDN's edge locations before users request it, and the CDN stores it until you replace or remove it. There is no cold-miss penalty and the origin can even go offline, but you own the work of distributing content and invalidating stale copies.

Difference between the models

Aspect	Pull-based	Push-based
Who populates the edge	CDN, on first miss	You, ahead of demand
First-request latency	Miss penalty at each edge	Already warm
Origin load	Occasional refetches	One-time upload per asset
Best for	Large or frequently changing catalogs	Small, stable, high-value assets
Content freshness control	TTL-driven expiry	Explicit push and purge

Trade-offs

Pull is low-effort and self-managing but leaks origin load on cold misses and gives you only coarse TTL control over freshness. Push guarantees warm edges and minimal origin dependence at the price of orchestrating uploads and invalidations yourself, which is wasteful for content that few users ever request. Most systems default to pull for broad catalogs and reserve push for a small set of predictable, high-value files such as a launch-day video.

Interview Tips

Say explicitly what you would cache at the edge (static assets, media) and what you would not (personalized or rapidly changing responses).
Name the model you are choosing and why, and mention cache invalidation, because purging stale content across many edges is the hard part.
Bringing up TTLs and cache-control headers shows you know how freshness is actually controlled.

Summary

A CDN caches content on edge servers near users to cut latency and offload the origin.
On an edge miss the request falls through to the origin, which is then cached.
Pull-based CDNs fetch lazily on first miss and need little setup.
Push-based CDNs are pre-loaded, stay warm, and reduce origin dependence.
Default to pull for large catalogs and push for small, stable, high-value assets.