CDNs — Content Delivery Networks

Imagine your origin server sits in Virginia. A user in Tokyo requests your homepage — that's a round trip of ~14,000 km, introducing 150–200ms of latency before they even see a byte. Do that for every image, every stylesheet, every video, and the experience degrades fast. CDNs solve this by moving content closer to whoever's asking for it.

What a CDN Does

A CDN is a globally distributed network of servers — called edge servers or Points of Presence (PoPs) — placed in cities and data centers around the world. When a user requests content, they're routed to the nearest edge server instead of hitting your origin. If the edge has the content cached, it responds instantly. If not, it fetches from origin, caches it, then responds.

Edge Servers

Edge servers are the CDN's front line. They sit geographically close to end users — in cities, ISP data centers, and internet exchange points — and serve cached copies of your content.

Key properties:

• Low latency — typically <20ms from major population centers
• High throughput — built to handle massive concurrent connections
• Automatic failover — if one edge goes down, traffic reroutes to the next nearest

Cache Hit vs Cache Miss

Cache hit — the edge server already has the requested content cached. It returns it immediately. Your origin server is never involved. This is fast and cheap.

Cache miss — the edge doesn't have the content yet (first request, or cache expired). It fetches from origin, stores a copy, then returns the response. The next request for the same content will be a cache hit.

Cache hit rate is the key metric. A good CDN deployment targets >90% hit rate, meaning the vast majority of requests never touch your origin.

What CDNs Cache

Always cached (static assets):

• Images, fonts, icons
• JavaScript and CSS bundles
• Video and audio files
• HTML pages (if content doesn't change per user)

Sometimes cached (dynamic content):

• API responses with appropriate Cache-Control headers
• Personalised pages with edge-side rendering
• Compressed or transformed variants of assets

Never cached:

• Authenticated requests with user-specific data (unless you explicitly configure it)
• POST/PUT/DELETE requests
• Responses with Cache-Control: no-store

TTL — Time to Live

Every cached item has a TTL — the duration it stays at the edge before the edge re-fetches from origin. Set via Cache-Control: max-age=<N> in your response headers.

Common TTL strategies:

• Static assets with hashed filenames (bundle.a3f9c.js) — TTL of 1 year. The hash changes when content changes, so you get indefinite caching without stale content risk.
• HTML pages — short TTL (60s–5min) or no-cache so users always get fresh markup.
• API responses — depends on how stale the data can be. A leaderboard might tolerate 30s; a bank balance should not be cached at all.

CDN Invalidation

When you deploy new code, cached assets at every edge server may be stale. Invalidation lets you tell the CDN to evict specific files before their TTL expires.

Approaches:

• Path invalidation — cloudfront.invalidate /assets/* — purge all files under a path
• Filename versioning — change the filename (via content hash) and the old cache is automatically orphaned
• Surrogate keys / cache tags — tag responses with logical keys (e.g. product-123), invalidate all edges by tag when that product updates

Invalidation propagates globally in seconds on major CDNs but has a cost — CloudFront charges per 1,000 invalidation paths. Versioned filenames sidestep this entirely.

Benefits

Lower latency. Requests are served from 10–50ms away instead of 150–200ms across continents.

Reduced origin load. If 95% of requests are cache hits, your origin servers handle 5% of the traffic. You can run fewer, smaller instances.

DDoS protection. CDNs absorb volumetric attacks at the edge — traffic gets distributed across hundreds of PoPs instead of slamming your origin. Cloudflare has absorbed attacks exceeding 1 Tbps.

Global availability. Even if your origin goes down briefly, edges continue serving cached content, keeping the site up for users.

Bandwidth savings. You pay edge egress rates (cheap) instead of origin egress rates (expensive) for the majority of traffic.

Real-World Tools

CDN	Notes
Cloudflare	Global network, DDoS protection built-in, free tier available. Most widely used.
AWS CloudFront	Deep AWS integration. Works with S3, ALB, API Gateway. Pay-per-use.
GCP Cloud CDN	Integrated with GCP load balancers. Automatic caching for GCS and backends.
Fastly	Edge compute (Compute@Edge), instant purging, used by GitHub, Stripe, NYT.
Azure CDN	Microsoft's offering. Integrates with Azure Blob Storage and Azure Front Door.

Tradeoffs

Stale content risk. If TTLs are too long and invalidation isn't done properly, users get outdated content. Versioned filenames + short HTML TTLs is the standard mitigation.

Cost at scale. CDN egress pricing adds up for high-traffic, large-file workloads like video. You're trading origin cost for edge cost — usually a good deal, but model it at your scale.

Invalidation complexity. Global cache purging, surrogate keys, and coordinating deploys with invalidation adds operational overhead.

Geographic blind spots. Not all CDNs have strong PoP coverage everywhere. Cloudflare has 300+ PoPs; smaller CDNs may have weak coverage in Southeast Asia or Africa.

Dynamic content caching footguns. Accidentally caching authenticated or user-specific responses at the edge is a serious data leak. Set Vary: Cookie and Cache-Control headers carefully.

Key Takeaways

• A CDN routes users to the nearest edge server, not your origin — reducing latency dramatically
• Cache hits serve content instantly without touching origin; cache misses fetch and store for next time
• Static assets with content-hashed filenames can be cached for a year; HTML pages should have short TTLs
• CDNs also reduce origin load, absorb DDoS traffic, and keep sites available during origin outages
• Cloudflare, CloudFront, Fastly, and Cloud CDN are the main players — pick based on your cloud provider and requirements

---

Next: Proxies — the difference between forward and reverse proxies, and where each fits in a system architecture.