CDN & the Edge

Learning goals

By the end of this chapter you should be able to:

• Explain origin vs edge and why CDNs exist
• Describe how cache keys decide hit vs miss
• Reason about stale content, TTLs, and purges
• Give an intuitive picture of Anycast — “one IP, many places”

A Content Delivery Network (CDN) puts copies of your content close to users so the long haul to your origin datacenter is not repeated for every eyeball on every asset.

Plain English: the latency problem

User in Tokyo fetching a 2 MB image from a server in Virginia travels thousands of kilometers each time unless something caches nearby.

A CDN runs edge PoPs (Points of Presence) worldwide. First request for logo.png might miss cache and pull from origin. Later requests in that region hit the edge copy — faster and cheaper for you.

CDNs also absorb traffic spikes (product launch, viral video) so your origin is not the only shield.

Precise terms:

• Origin — your source server or bucket (S3, GCS, custom nginx).
• Edge — CDN cache node serving end users.
• Cache hit — edge had the object; no origin fetch.
• Cache miss — edge fetched from origin (or parent tier).

What CDNs cache (and what they should not)

Great CDN candidates:

• Static assets (JS, CSS, images, fonts)
• Cacheable API GET responses (with correct headers)
• Video segments (HLS/DASH)
• Whole static HTML pages (marketing sites)

Poor candidates without care:

• Personalized HTML per user with no Vary discipline
• POST responses
• Sensitive authenticated data with wrong Cache-Control

The CDN is a shared cache in front of many users — mis-set headers can leak one user’s response to another (classic Authorization + missing private bug).

Cache keys: how the edge decides “same object”

When a request arrives, the edge computes a cache key — usually derived from:

• URL (scheme, host, path, query string — query often included by default)
• Selected headers (Accept-Encoding, Accept-Language, custom Vary headers)
• Sometimes cookies (dangerous for static assets if misconfigured)

Two requests with different keys = two cache entries.

Example pitfall: app.js?v=1 vs app.js?v=2 are different keys — good for cache busting, bad if you generate infinite unique query params.

Normalization: CDNs let you ignore certain query params in the key (utm_* tracking junk) while still forwarding them to origin.

Precise term: Vary header tells caches which request headers must differentiate stored responses.

TTLs, freshness, and stale content

Objects live in edge cache for a Time To Live (TTL) from:

• Cache-Control: max-age=3600 on the response
• CDN default TTL if origin is vague
• Origin rules in CDN dashboard (override per path)

After TTL expires, the object is stale. Behavior depends on policy:

• Strict: revalidate with origin every time (slower, freshest).
• Stale-while-revalidate: serve stale instantly; refresh in background.
• Stale-if-error: if origin down, serve stale (availability win).

Purges / invalidations: you changed logo.png but edges still have old bytes — bump filename (logo.v2.png), or purge URL/path via API. Purge propagation is not instant globally — plan for seconds to minutes.

Soft purge vs hard purge (vendor-specific): may serve stale while re-fetching.

Origin shield and tiered caches

Large CDNs use regional mid-tiers so one origin fetch fills many edge PoPs — origin shield reduces thundering herd when a popular object expires everywhere at once.

Mental model:

User → Edge PoP → (maybe) Regional cache → Origin

If 10,000 edges miss simultaneously, shield collapses to one origin pull.

Anycast intuition: one IP, nearest PoP

Many CDNs advertise the same IP address from many locations using BGP Anycast. Routing sends packets to the topologically nearest PoP that announces that prefix.

User does not pick “Tokyo edge vs London edge” — Internet routing picks for them.

Benefits:

• Simple DNS (api.example.com → one anycast IP).
• Automatic failover if a PoP stops announcing routes.

Not magic: Anycast is about network entry point, not cache coherence. Each PoP still has its own cache; first user in a city may miss.

Contrast GeoDNS: different IPs per region — user resolves to nearest via DNS logic, not BGP.

Modern CDNs also terminate TLS, scrub DDoS, and run edge workers — but the baseline story stays: cache static assets, respect headers, purge thoughtfully.

Headers you should know

s-maxage: applies to shared caches (CDN), can differ from browser max-age.

Common mistakes

1. Caching HTML with Set-Cookie user sessions — personalize at edge wrong → wrong user sees wrong page.
2. Forgetting query strings in cache key — /api?user=1 cached served to ?user=2.
3. Infinite TTL on HTML — deploy changes invisible until purge.
4. Assuming purge is immediate worldwide — always have cache-bust strategy.
5. Origin allows CDN IPs but blocks health checks — 502 loops.

Practice checkpoint

1. Cache hit vs miss — which touches origin? Answer: miss (or revalidation requiring origin); hit served from edge.

2. Why include v=abc123 in static asset URLs? Answer: cache bust — new URL = new cache key; no stale JS after deploy.

3. What does Cache-Control: private tell a CDN? Answer: do not store in shared cache; intended for one user’s browser only.

4. Anycast vs GeoDNS in one sentence each? Answer: Anycast = same IP announced in many places, routing picks nearest; GeoDNS = DNS returns different IPs per user region.

5. Stale-while-revalidate — user experience during revalidation? Answer: user gets fast stale copy while CDN refreshes in background.

Interview angles

• Why CDN: latency, bandwidth cost, absorb spikes, TLS/WAF at edge.
• Cache key design for APIs — which headers belong in Vary.
• Thundering herd on expiry — shield, stale serving, single-flight origin lock.
• Invalidation strategies: fingerprinted assets vs purge API tradeoffs.
• Dynamic site still uses CDN for static /assets/* while HTML from origin.

Next: /networking/learn/systems/nat-firewalls-private-networks/