How CDNs Cache and Serve Dynamic Content

Introduction

A Content Delivery Network (CDN) is a globally distributed network of Points of Presence (PoPs) — data centers positioned close to end users in major cities worldwide. When a user requests cdn.example.com/image.jpg, instead of traveling to a single origin server in Virginia, their request is routed via Anycast BGP to the nearest PoP — perhaps 5ms away in their city instead of 80ms away across an ocean. The PoP either serves the content from its edge cache (a cache hit) or fetches it from origin and caches it (a cache miss).

Modern CDNs like Cloudflare, Fastly, and AWS CloudFront have evolved far beyond static file caching. They now handle dynamic API responses, personalized content, and even run serverless compute at the edge.

Step-by-Step: Request Lifecycle

flowchart TD
    A["1. DNS and Anycast Routing"]
    B["2. Cache Key Construction"]
    C["3. Cache-Control Header Evaluation"]
    D["4. Origin Shield"]
    E["5. Dynamic Content Strategies"]
    A --> B
    B --> C
    C --> D
    D --> E

Step 1: DNS and Anycast Routing

User types: api.example.com
  → DNS resolves to 104.18.21.10 (Cloudflare Anycast IP)
  → BGP routes to nearest PoP (e.g., Frankfurt)
  → PoP handles request (no ocean round-trip)

Step 2: Cache Key Construction

The CDN checks its edge cache using a cache key — typically the URL + selected headers:

Default key: GET https://api.example.com/products?category=shoes
Custom key: + Accept-Language header (for locale-specific responses)
            - Cookie header (strip auth cookies to improve hit rate)

Badly configured cache keys (including all cookies) collapse hit rates to near zero. Stripping session cookies and normalizing query parameter order dramatically improves cache efficiency.

Step 3: Cache-Control Header Evaluation

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

• public: CDN is allowed to cache this response
• max-age=3600: Serve from cache for 1 hour before checking origin
• stale-while-revalidate=60: Serve stale content for 60s while fetching fresh copy in background (eliminates latency spikes at TTL boundary)

Step 4: Origin Shield

Without origin shield, 200 global PoPs × cache miss = 200 simultaneous requests to origin (thundering herd). Origin Shield designates one central PoP as the sole gateway to origin — all other PoPs check origin shield first:

PoP (Frankfurt) MISS → Origin Shield (London) HIT → served
PoP (Singapore) MISS → Origin Shield (London) MISS → Origin fetched, cached
PoP (New York)  MISS → Origin Shield (London) HIT → served (from shield cache)

Step 5: Dynamic Content Strategies

For personalized or real-time content, CDNs use:

• Edge-Side Includes (ESI): Cache page template at edge, fetch only the personalized fragment from origin
• Vary header: Cache separate versions per Accept-Encoding or Accept-Language
• Bypass conditions: Cache-Control: private or presence of session cookies skips cache entirely

# Nginx origin: cache product pages but bypass for logged-in users
set $no_cache 0;
if ($http_cookie ~* "session_id") { set $no_cache 1; }
add_header Cache-Control "public, max-age=300, stale-while-revalidate=30";

Key Takeaways

• CDNs use Anycast BGP to route users to the nearest PoP — not DNS geo-routing, which has TTL lag.
• Cache key design is the most impactful tuning lever: strip irrelevant cookies, normalize query params.
• stale-while-revalidate eliminates TTL expiry latency spikes by allowing background cache refresh.
• Origin Shield collapses all PoP-to-origin traffic through a single gateway, protecting origin from thundering herd.
• Dynamic personalization uses ESI, Vary headers, or cache bypass conditions — not disabling CDN entirely.