CDN & Edge Caching

Tier 1 — Building Block

1. What Is It?

A Content Delivery Network (CDN) is a globally distributed network of servers — called Points of Presence (PoPs) or edge nodes — that cache content geographically close to end users. When a user requests content (an image, video, JS bundle, or API response), the CDN serves it from the nearest edge node instead of routing all the way back to your origin server.

Without a CDN, a user in Tokyo requesting content from a US-East origin server suffers ~140ms round-trip latency — just for the network hop. With a CDN edge node in Tokyo, that same request is served from ~5ms away. More importantly, CDNs absorb the majority of traffic at the edge, protecting your origin from massive read load. A well-configured CDN can handle 95%+ of static asset requests without ever touching the origin.

Edge caching is the underlying mechanism: CDN nodes store cached copies of responses and serve them directly to users during the TTL (Time-To-Live) window — the period a cached copy is considered fresh — only fetching from origin on a cache miss.

2. How It Works

Cache Hit (Edge Serves Directly)

-+ResetFullscreen

Cache Miss (Origin Pull)

-+ResetFullscreen

CDN Architecture

-+ResetFullscreen

Cache Control Headers

The CDN respects HTTP Cache-Control and Expires headers from the origin:

3. Variants & Comparisons

Push CDN vs. Pull CDN

Static vs. Dynamic Content Caching

Major CDN Providers

4. When to Use It (and When NOT To)

Use a CDN When:

• Globally distributed users — users in multiple geographies experiencing high latency to your origin
• Static asset heavy — JS, CSS, images, fonts: perfect for CDN caching
• High read traffic — offload repeated GET requests from your origin servers
• Video/large media — byte-range requests, streaming protocols (HLS, DASH) — CDN is essentially mandatory
• DDoS protection needed — CDN absorbs volumetric attacks at the edge before they reach origin

Decision triggers:

• "If your P99 latency for static assets is >200ms for overseas users → add CDN"
• "If static assets account for >50% of your request volume → CDN will dramatically reduce origin load"
• "If you're serving video → CDN is non-negotiable (origin cannot serve concurrent streams at scale)"

Do NOT Use CDN For:

• Personalized responses — CDN would cache User A's data and serve it to User B. Always set Cache-Control: private or no-cache for user-specific content.
• Highly dynamic APIs — if cache hit rate < 5%, CDN adds latency (a miss is always slower than going directly to origin due to the extra hop)
• Sensitive/PII data in URLs — some CDN logs request URLs; avoid putting tokens or IDs in query params

Anti-patterns:

• Caching authenticated responses — forgetting to set Cache-Control: private on user-specific API responses. CDN will serve cached user A data to user B.
• No cache-busting for static assets — deploying new CSS with the same filename. Users get stale CDN cache. Fix: content hash in filename (app.[hash].css) + immutable TTL.
• Not using cache invalidation on deploys — new deploy requires immediate TTL-independent purge of old assets. Have a deploy step that calls CDN purge API.
• Forgetting the Vary header — if your origin returns different content for Accept-Encoding: gzip, CDN must cache gzipped and non-gzipped versions separately. Vary: Accept-Encoding tells CDN to key cache by encoding.

5. Real-World Usage

Netflix: Netflix uses a custom CDN called Open Connect — dedicated appliances (servers with large SSD/HDD storage) placed inside ISPs worldwide. Netflix pre-positions popular content to Open Connect appliances at night during off-peak hours (push CDN model). During peak evening streaming hours, ~95% of Netflix traffic is served directly from Open Connect within the ISP, never touching Netflix's origin. This is why Netflix can serve 15% of global internet traffic during peak hours.

GitHub (Fastly): GitHub uses Fastly for CDN. Fastly's key feature for GitHub is instant purge (~150ms global TTL invalidation). When a user pushes code, GitHub must immediately invalidate cached pages for that repository. With traditional CDN TTLs, a 1-hour TTL would show stale README pages for up to 1 hour. Fastly's surrogate keys allow GitHub to invalidate all pages related to a repo with a single API call.

Cloudflare Workers (edge compute): Cloudflare Workers allow running JavaScript at edge PoPs, not just caching. Companies like Discord use Workers to authenticate requests, transform responses, and implement A/B testing at the edge — eliminating an entire round-trip to origin for logic that used to live in the app server. This represents the evolution of CDN from "cache static assets" to "run compute at the edge."

6. Interview Cheat Sheet

Key sentences to demonstrate depth:

1. "A CDN reduces latency by serving content from geographically close edge nodes and reduces origin load by absorbing cache hits — a well-tuned CDN handles 95%+ of static traffic without touching origin."
2. "The key CDN decision is what to cache: static assets with long TTLs and filename-based cache busting are a perfect fit; personalized API responses must never be cached at a shared edge node."
3. "CDN invalidation is the hard part — for static assets I use content-addressed filenames (hash in URL) with immutable TTLs, eliminating the invalidation problem. For semi-static content I use the CDN's purge API on deploy."
4. "A 'shield' or 'mid-tier' PoP collapses cache misses from many edge nodes into a single origin request — without it, a burst of misses from 100 edge nodes all simultaneously hit origin."
5. "CDNs are also DDoS mitigation — they absorb volumetric attacks at the edge's massive bandwidth capacity before packets reach your origin."

Common follow-up questions:

Connections to other building blocks:

• Caching Strategies: CDN implements cache-aside semantics (miss → origin pull → cache at edge). HTTP Cache-Control headers are the CDN's TTL mechanism.
• Load Balancing: CDN typically sits in front of your load balancer. Load balancer distributes among origin app servers; CDN distributes globally across PoPs.
• Read Replicas: CDN handles static/semi-static content; read replicas handle dynamic database reads. Together they cover most read traffic.
• Rate Limiter: CDNs often provide rate limiting at the edge — block abusive IPs before traffic hits your origin. Cloudflare, Fastly both support edge rate limiting rules.
• Consistent Hashing: Large CDN networks use consistent hashing internally to route requests to the same edge node for a given URL (maximizing cache hit rates across CDN nodes).