CDN

7 min read

In a Nutshell

A CDN (Content Delivery Network) is a globally distributed fleet of caching servers ("edge" locations) that store copies of your content close to users. Instead of every request traveling to your origin server — possibly on another continent — users are served from the nearest edge, cutting latency from hundreds of milliseconds to tens. CDNs originally cached static assets (images, CSS, JS, videos), but modern ones also accelerate dynamic content, terminate TLS, absorb DDoS attacks, and run code at the edge. For any system with a geographically-spread audience, a CDN is one of the highest-leverage performance and reliability additions you can make.

2D minimalistic world-map-style diagram showing a single origin server in one location and many edge/CDN nodes spread across the globe; users near each edge node connect to their local edge (short arrows) instead of all reaching back to the distant origin (one long dashed arrow), illustrating reduced latency

How It Actually Works

Why Distance Is Latency

Data can't travel faster than light, and real networks are slower. A round trip across the world adds real, unavoidable delay:

User in Sydney → origin in Virginia (~16,000 km):
  ~200ms round trip PER request, before the server even does work.
  A page with 50 assets could add seconds.

User in Sydney → Sydney edge node (~10 km):
  ~5ms round trip. The edge serves cached content instantly.

The CDN's core value is turning a long, slow path into a short, fast one for the majority of requests.

The Cache Hit/Miss Flow

Request arrives at nearest edge:
   ┌─ Cache HIT  → serve from edge immediately (fast, no origin load)
   │
   └─ Cache MISS → edge fetches from origin (or a mid-tier cache),
                   stores it per Cache-Control/TTL,
                   serves it, and has it ready for the next user

The cache hit ratio is the key metric: a 95% hit ratio means only 5% of requests ever reach your origin, which slashes origin load and cost while improving latency.

What CDNs Cache — and How Freshness Is Controlled

Content Type	Cacheable?	Mechanism
Static assets (images, JS, CSS, fonts, video)	Easily	Long TTL + versioned URLs
Dynamic API responses	Sometimes	Short TTL, `Cache-Control`, edge rules
Personalized content	Rarely	Usually bypass or edge-compute

Freshness is governed by HTTP caching headers (Cache-Control, ETag, max-age) — the same mechanisms from HTTP & HTTPS. Two techniques dominate:

Cache-busting via versioned URLs: app.a1b2c3.js — change the content, change the filename, so caches never serve stale code. Lets you use very long TTLs safely.
Purge / invalidation: explicitly evict content from all edges when it changes (e.g., after a deploy or content update).

Push vs Pull CDNs

Model	How Content Gets to the Edge	Best For
Pull	Edge fetches from origin on first miss, then caches	Most sites; content served on demand
Push	You proactively upload content to the CDN	Large files, predictable hot content, video

Pull is the common default (set-and-forget); push gives you control for big/critical assets.

Beyond Caching: The Modern CDN

CDNs have grown into a full edge platform:

TLS termination at the edge — faster handshakes closer to users.
DDoS protection & WAF — absorb and filter attacks before they reach origin (Anycast spreads the load).
Edge compute — run functions at the edge (Cloudflare Workers, Lambda@Edge) for personalization, auth, A/B tests without an origin round trip.
Origin shield — a mid-tier cache that further reduces origin traffic and protects it during traffic spikes.

2D minimalistic diagram showing the CDN request flow: a user hits the nearest edge node; on a cache hit the edge returns content directly (green fast path), on a cache miss the edge forwards to an origin-shield mid-tier cache and then the origin (longer path), with the fetched content stored at the edge for future requests

Seeing It in Action

Scenario: Adding a CDN to a media-heavy web app.

Before:
  All users → single origin (us-east). Global users see 300–800ms.
  Origin serves every image, JS bundle, and video chunk → high load.

After (CDN in front):
  Static assets (images, JS, CSS, video):
    - Versioned URLs: /assets/app.9f8a.js  → Cache-Control: max-age=1yr
    - First user in a region: MISS → edge fetches from origin
    - Everyone after: HIT → served from local edge in ~10ms
    - Origin load drops ~90%+

  HTML / API:
    - HTML: short TTL (60s) or edge-cached with purge on publish
    - Personalized API: bypass cache OR use edge compute for auth

  Deploy flow:
    - New bundle → new hash in filename → new URL → no stale JS ever
    - Purge only the HTML that references the bundle

Result:
  - Global latency: 300–800ms → 10–50ms for cached content
  - Origin bandwidth and CPU cut dramatically → lower cost
  - Traffic spikes absorbed at the edge → origin protected

The compounding win: the CDN improves latency (nearest edge), cost (fewer origin bytes), scalability (edge absorbs spikes), and reliability (origin protected, DDoS absorbed) — all from one architectural addition. That combination is why CDNs are nearly universal for user-facing systems.

Interview Questions

Q: How does a CDN reduce latency, and what's the key metric to watch? Hint: It caches content at edge locations geographically close to users, so requests travel a short distance instead of to a distant origin (physics: less distance = less round-trip latency). The key metric is cache hit ratio — a high ratio means most requests are served from the edge, minimizing origin load and latency. Aim to maximize it via good TTLs and cache keys.
Q: How do you serve fresh content through a CDN without users getting stale files? Hint: Two main techniques: versioned/fingerprinted URLs (e.g., app.a1b2c3.js) so changed content has a new URL and long TTLs are safe, and explicit purge/invalidation to evict content from edges on change. Use HTTP caching headers (Cache-Control, ETag) to control TTL and revalidation. Personalized content is typically bypassed or handled by edge compute.
Q: What's the difference between a push and a pull CDN? Hint: Pull: the edge fetches content from the origin on the first cache miss, then caches it — on-demand, set-and-forget, ideal for most sites. Push: you proactively upload content to the CDN ahead of time — better control for large files, video, or predictable hot content you don't want to incur an origin miss for.
Q: Besides caching static assets, what else do modern CDNs do? Hint: TLS termination at the edge, DDoS protection and WAF (Anycast absorbs/filters attacks before origin), edge compute (run functions near users for auth/personalization/A-B without origin round trips), origin shield (mid-tier cache protecting the origin), and dynamic content acceleration via optimized routing and connection reuse.
Q: What content is hard to cache in a CDN, and how do you handle it? Hint: Personalized/authenticated and rapidly-changing dynamic content — caching it risks serving one user's data to another or showing stale info. Handle via cache bypass, very short TTLs with cache keys that include relevant vary headers, segmenting cacheable vs non-cacheable parts (cache the shell, fetch personalized bits), or edge compute that personalizes at the edge.

References

Cloudflare: What is a CDN? — clear conceptual primer
High Performance Browser Networking by Ilya Grigorik — latency, caching, and delivery
MDN: HTTP caching — the headers that drive CDN behavior

Dive Deeper

Fastly: How caching works — cache keys, TTLs, and purging in depth
Cloudflare Workers — running code at the edge
Netflix Open Connect — a purpose-built CDN for video at massive scale