How CDNs Work — Edge Caching, PoPs, and Content Delivery at Scale

The latency problem CDNs solve#

Your server is in Virginia. A user in Tokyo requests your page. The round trip takes 200ms just for the network — before your server even starts processing.

A CDN places copies of your content on servers close to users. That Tokyo user hits an edge server in Tokyo — 10ms round trip instead of 200ms.

How CDNs work#

Points of Presence (PoPs)#

CDN providers operate hundreds of PoPs worldwide. Each PoP has edge servers that cache and serve content.

User in Tokyo → PoP in Tokyo (10ms)
User in London → PoP in London (5ms)
User in São Paulo → PoP in São Paulo (15ms)
All serving the same content from your origin in Virginia

DNS-based routing#

When a user requests cdn.example.com:

1. DNS resolver asks the CDN's authoritative nameserver
2. CDN nameserver returns the IP of the nearest PoP (using GeoDNS or Anycast)
3. User connects to the closest edge server
4. Edge server either serves from cache (hit) or fetches from origin (miss)

Cache hit vs. miss#

Cache hit: Edge server has the content → serves directly. Fast.

Cache miss: Edge server doesn't have the content → fetches from origin, caches it, then serves. Slow for the first request, fast for subsequent ones.

Cache hit ratio is the key metric. Good CDNs achieve 90-99% hit rates for static content.

What to put on a CDN#

Always CDN:

• Images, videos, fonts, CSS, JavaScript
• Static HTML pages
• Downloads (PDFs, installers, packages)

Sometimes CDN:

• API responses (with short TTL)
• Dynamic HTML (with edge computing)
• Personalized content (via edge functions)

Never CDN:

• Write operations (POST, PUT, DELETE)
• Real-time data (use WebSockets instead)
• Highly personalized pages (unless using edge compute)

Caching strategies#

Cache-Control headers#

Your origin server tells the CDN how long to cache:

Cache-Control: public, max-age=31536000, immutable

• public — CDN can cache this
• max-age=31536000 — Cache for 1 year
• immutable — Content will never change (versioned assets)

TTL patterns#

Stale-While-Revalidate#

Cache-Control: max-age=60, stale-while-revalidate=3600

Serve stale content immediately while fetching fresh content in the background. Users get instant responses even when cache expires.

Cache invalidation#

The hardest problem in CDNs. When content changes, you need to clear cached copies across hundreds of PoPs.

Purge by URL: Delete specific URLs from all edge caches. Purge by tag: Tag content with categories, purge by tag (e.g., purge all "product-images"). Purge everything: Nuclear option. Empties all caches. Causes a stampede to origin.

Best practice: Use versioned URLs (hash in filename). Never purge — old versions are naturally replaced by new ones.

Edge computing#

Modern CDNs run code at the edge — not just cache content:

• Cloudflare Workers — JavaScript at 300+ locations
• Vercel Edge Functions — Next.js middleware at the edge
• AWS Lambda@Edge — Run Lambda at CloudFront PoPs

Use cases: A/B testing, auth checks, geo-routing, header manipulation, HTML rewriting.

Multi-tier CDN architecture#

Large CDNs have multiple tiers:

User → Edge PoP (closest) → Regional PoP (mid-tier) → Origin Shield → Origin Server

Origin Shield: A single point between the CDN and your origin. Reduces origin load by consolidating cache misses from multiple PoPs.

Visualize your CDN architecture#

See how edge servers, origin, and routing connect — try Codelit to generate an interactive diagram of your CDN infrastructure.

Key takeaways#

1. CDNs reduce latency by serving from edge servers close to users
2. Cache-Control headers control caching behavior — set them deliberately
3. Versioned URLs eliminate the need for cache purging
4. Stale-while-revalidate gives instant responses while refreshing in background
5. 90%+ hit rate is the target for static content
6. Edge computing extends CDNs beyond caching to running code at the edge