Stage 4 · Provision
Data Systems at Scale
CDN & Edge Design
Anycast, origin shielding, stale-while-revalidate, and cache-key design for CDN performance.
CDN Fundamentals
A Content Delivery Network (CDN) caches content at edge locations worldwide. When a user requests content, the CDN serves it from the nearest edge node. This reduces latency, offloads the origin, and provides DDoS protection. CDNs are critical infrastructure for any global application.
Anycast Routing
Anycast advertises the same IP address from multiple CDN edge locations. BGP routes users to the nearest edge based on network topology. This provides automatic failover and load distribution without DNS-based routing.
User in Tokyo ──BGP──► Nearest CDN edge (Tokyo)
│ │
│ cache hit ──────────► Serve from edge (1ms)
│
cache miss
│ │
└──► Fetch from origin ──► Cache at edge ──► ServeAnycast ensures users always connect to the nearest edge. If one edge goes down, BGP reroutes traffic to the next closest. This provides inherent resilience.
Origin Shielding
Origin shielding places a caching layer between edge nodes and the origin server. When an edge node has a cache miss, it fetches from the shield instead of the origin. This reduces origin load from hundreds of edge requests to a single shield request.
Edge Node (Tokyo) ──cache miss──► Origin Shield (US-East)
Edge Node (London) ──cache miss──► │
Edge Node (Sydney) ──cache miss──► │
│
Origin Server (US-East)
Without shield: 3 edge nodes hit origin
With shield: 1 shield hits origin, 3 edges hit shieldOrigin shielding dramatically reduces origin load. CloudFront, Fastly, and Cloudflare all support origin shielding configuration.
Cache Key Design
The cache key determines which requests share a cached response. A good cache key includes all request attributes that affect the response. A bad cache key either caches too much (serving wrong content) or too little (missing cache hits).
Good cache key: /api/products?category=electronics&sort=price
Includes path + query parameters that affect results
Bad cache key: /api/products
Caches same response for all categories and sorts
Vary header: Vary: Accept-Encoding, Authorization
Cache separate responses for different encodings/auth states
Normalized key: /api/products?category=electronics&sort=price&page=1
Remove tracking params (utm_source, fbclid) that don't affect responseDesign cache keys to be specific enough to serve correct content but broad enough to maximize cache hits.
Stale-While-Revalidate
Stale-while-revalidate serves stale cached content immediately while refreshing the cache in the background. This provides fast responses to users while keeping content fresh. It is configured via Cache-Control headers.
Cache-Control: max-age=60, stale-while-revalidate=300
Timeline:
0s - Content cached
60s - max-age expires
60s - Serve stale content, revalidate in background
61s - Fresh content cached, stale content still served
360s - stale-while-revalidate expires, must revalidateThis eliminates the latency penalty of cache expiration. Users always get fast responses, and the cache is refreshed in the background.
CDN Cache Invalidation
- Purge API — Instant invalidation by URL or cache tag. Fast but costs money.
- TTL-based — Set short TTLs for dynamic content. Simple but slow to propagate.
- Versioned URLs — Include version in URL (style.v2.css). Old cache expires naturally.
- Surrogate keys — Tag cached objects, purge all objects with a tag.
For static assets (JS, CSS, images), include a content hash in the filename (main.a1b2c3.js). This makes cache invalidation automatic — the old file expires naturally when the URL changes.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.