How a CDN Brings Content Close to You

Core idea

A CDN spreads edge nodes worldwide, caching static content near users. The origin serves once; afterwards responses come from nearby, cutting latency and origin load.

How a request reaches the edge

1. The user hits cdn.example.com; DNS returns the nearest edge IP by location;
2. The edge serves from cache on a hit;
3. On a miss it fetches from the origin, caches, then returns.

Two cache actions

What belongs on a CDN

• Good: images, scripts, styles, fonts, video -- static assets;
• Bad: dynamic content with private user data (it would leak to others); mark those Cache-Control: private or serve from origin.

Real-world cases: three CDN misconfigurations

1. Caching private content at the edge: an endpoint carrying user data without Cache-Control: private gets cached and served to others. Private dynamic responses must be marked uncacheable or keyed per user.
2. Old pages after a release: HTML cached for a long time shows the previous version, which calls retired endpoints. Cache HTML briefly or with must-revalidate; only hashed static assets deserve long caching.
3. Wrong Host header on origin fetch: without the right Host the origin routes to its default vhost and returns 404. Keep origin settings consistent with the origin's virtual hosts.

FAQ

Does a CDN hurt security? No, but configure it: HTTPS, origin authentication, cache keys and isolation of private content. Is a higher hit rate always better? For static assets yes; for dynamic content correctness comes first. How do I make a release take effect immediately? Change URLs with filename hashes, or give HTML a short TTL and purge actively. How are nearby nodes chosen? DNS or Anycast steering, with cache warming to cut the first origin fetch.

Edge logic and cache key design

Modern CDNs do more than cache — they run logic at the edge. Done well it relieves the origin; done badly it creates problems you cannot reproduce:

• Define the cache key explicitly: the default is usually the URL alone; if the response varies by language, device or session, include those dimensions or you will serve one user's content to another;
• Handle query strings: ignore irrelevant parameters (marketing tags) to reduce cache fragmentation, but keep those that genuinely change the body;
• Keep edge logic simple: redirects, auth forwarding and A/B splits suit the edge; complex business logic there is hard to debug and drifts from the app;
• Protect the origin: set origin timeouts, retry counts and concurrency caps so a wobble is not amplified into an avalanche;
• Warm and purge deliberately: pre-warm hot content before a sale or release, and purge changed paths specifically rather than flushing everything.

Decide caching as part of the API contract — Vary and Cache-Control belong in the spec, not bolted on afterwards.

Troubleshooting and capacity view

1. Confirm where the response came from: read the cache status header first to see whether it came from the edge or the origin. Persistent origin fetches point at cache keys or headers, not origin performance.
2. Watch regional differences: the same content behaving differently by region usually means un-warmed nodes or uneven origin links — track metrics per region, not just global averages.
3. Plan for peak bandwidth: estimate the traffic a campaign brings and confirm your plan or billing model covers it, or you get throttled at the worst moment.
4. Protect against origin stampedes: mass cache misses hit the origin at once; batch and rate-limit purges, or run them off-peak.
5. Version configuration changes: keep the previous cache rules and edge logic switchable — a bad configuration usually has a wider blast radius than bad code.

Treating the CDN as a system needing capacity planning and change management, rather than a set-and-forget asset channel, is what keeps it stable.