CDNs & the Edge

Before this

• HTTP Caching — Cache-Control, ETags, and revalidation — the cheapest performance win that exists.
• DNS — A globally distributed, aggressively cached phone book — and the reason your deploy 'didn't work' for 20 minutes.

Why this exists

No matter how optimized your backend database queries or rendering pipelines are, the speed of light is a hard limit: a request traveling across the globe will take at least 150ms just in transit round-trips. Before Content Delivery Networks (CDNs), every asset request had to navigate across multiple backbones to a centralized origin server, leading to sluggish load times and origin collapse during traffic spikes.

The mental model

A CDN is like a network of neighborhood convenience stores. Instead of driving across the country to the central manufacturing warehouse whenever you need milk, you walk to the local corner bodega, which keeps popular items stocked locally and only restocks from the central warehouse when an item is missing or expired.

How it works

The mechanism

1. **DNS Lookup:** Client resolves the domain, receiving an Anycast IP that routes to the nearest PoP. 2. **Handshake:** Client completes TCP and TLS handshakes with the local edge server in single-digit milliseconds. 3. **Cache Lookup:** Edge server hashes the request into a cache key and checks its memory/SSD cache tiers. 4. **Cache Hit:** If found and fresh, the edge server immediately streams the cached response payload. 5. **Cache Miss & Origin Shielding:** If absent, the edge fetches the asset from an intermediary 'Origin Shield' or directly from the origin server, stores a copy locally according to `Cache-Control` directives, and returns it to the client.

sequenceDiagram
  autonumber
  actor User
  participant Edge as CDN PoP (Edge)
  participant Origin as Origin Server

  User->>Edge: 1. TCP/TLS Handshake (5ms)
  User->>Edge: 2. GET /static/app.js
  alt Cache Hit
    Edge-->>User: 3a. 200 OK (Cached Payload)
  else Cache Miss
    Edge->>Origin: 3b. GET /static/app.js (via optimized backhaul)
    Origin-->>Edge: 4b. 200 OK + Cache-Control: max-age=86400
    Edge->>Edge: Store in Edge Tier
    Edge-->>User: 5b. 200 OK (Stream payload)
  end

What people get wrong

CDNs are only useful for static files like images, CSS, and JS bundles.

CDNs accelerate dynamic, uncached requests through edge TLS termination, connection pooling, and optimized route-peering back to origin. Even with a 0% cache hit rate, performing the TLS handshake nearby and reusing warm, persistent TCP connections over private fiber backbones significantly reduces total TTFB (Time to First Byte).

Setting a long TTL and relying on manual CDN cache purges is sufficient for cache invalidation.

Purge propagation takes time and can fail; asset hashing (fingerprinting in filenames) is the only truly deterministic cache-busting strategy. Edge networks contain thousands of servers. Global purges take seconds to minutes to propagate across all PoPs, during which stale assets can cause fatal version mismatches in client apps.

Running edge compute functions is an exact replacement for your backend API server.

Edge compute is designed for fast, stateless, I/O-light transformations, not heavy compute or multi-table transactional database operations. Edge runtimes run in strict isolation with tight memory limits and CPU execution timeouts. If an edge function has to query a centralized SQL database across the world anyway, it negates the edge latency benefit.

When not to use it

Heavily write-intensive workloads with strict ACID consistency across global transactions.

Centralized transactional databases (e.g., PostgreSQL) or distributed SQL systems with dedicated Raft consensus (e.g., CockroachDB/Spanner) behind a regional API gateway.

Real-time bidirectional streaming with stateful local memory requirements (e.g., game server loops, stateful WebSockets).

Dedicated regional application servers or specialized game server orchestration frameworks (e.g., Agones on Kubernetes).

Ultra-sensitive, highly regulated on-premise PII processing where third-party TLS termination is prohibited.

Private direct-connect lines and dedicated on-premise reverse proxies with end-to-end hardware encryption.

Terms

PoP (Point of Presence)

— A local data center situated near end users that houses CDN edge servers and networking hardware.

BGP Anycast

— A network routing method where multiple physical locations share the same IP address, directing users to the nearest node.

Origin Shield

— A centralized caching tier placed between edge PoPs and the origin server to prevent thundering herd requests on cache misses.

Surrogate Keys (Cache Tags)

— Metadata labels assigned to cached content that allow granular, group-level cache purging with a single API call.

Connected ideas

• Rendering Strategies — Static, server, incremental — choosing per route based on how fresh the data must be.

Also part of

This idea matters in more than one area — which is usually why it matters.

• HTTP Semantics