CDN & Edge Networking

How It Works

A CDN is conceptually simple: put copies of content on servers close to the users. The implementation, however, involves elegant engineering at global scale.

The Request Flow

When a user in Tokyo requests https://example.com/image.jpg, here's what happens:

1. DNS Resolution via Anycast

The domain resolves to an Anycast IP address. Unlike regular unicast (one IP = one server), Anycast means the same IP is announced from every PoP worldwide. BGP routing automatically sends the user's packets to the nearest PoP. No geo-DNS databases, no region detection — the network itself routes optimally.

2. TLS Termination at the Edge

The edge PoP terminates TLS, meaning the client's TCP+TLS handshake happens with a server 10ms away instead of 200ms away. This alone saves 200-400ms on a cold connection to a distant origin.

3. Cache Lookup

The edge server computes a cache key (typically the URL path + relevant headers) and checks its local cache. Three outcomes:

• HIT: Content is cached and fresh. Return immediately. Total latency: 5-20ms.
• STALE: Content is cached but expired. Serve the stale version while revalidating with origin in the background (stale-while-revalidate).
• MISS: Content is not cached. Forward the request up the chain.

4. Shield Tier (Mid-Tier Cache)

On a cache miss, the edge doesn't go directly to origin. It routes to a shield (or mid-tier) cache — a regional cache shared by multiple edge PoPs. This is critical: without the shield tier, a cache miss at all 300 edge PoPs simultaneously would hit the origin with 300 requests for the same content. The shield collapses these into one origin request.

5. Origin Fetch

If the shield also misses, it fetches from the origin server. The response flows back through shield → edge → client, getting cached at each tier along the way.

Cache-Control: The Contract Between Origin and CDN

Everything about CDN behavior is controlled by HTTP cache headers. Get these wrong and the CDN is either useless (caching nothing) or dangerous (serving stale content).

# Cache for 1 hour at both CDN and browser
Cache-Control: public, max-age=3600

# Cache at CDN for 1 day, but browser only caches for 5 minutes
Cache-Control: public, max-age=300, s-maxage=86400

# Serve stale while revalidating in background (best for dynamic content)
Cache-Control: public, max-age=60, stale-while-revalidate=300

# Never cache (but the CDN still terminates TLS and provides DDoS protection)
Cache-Control: private, no-store

The s-maxage directive is CDN-specific — it overrides max-age for shared caches (CDN, reverse proxy) while letting the browser cache with a different TTL. This enables aggressive CDN caching while keeping browser caches short for faster updates.

Cache Key Design

The cache key determines what's a "hit" and what's a "miss." The default key is usually the full URL including query string. This means:

/api/products?page=1          → cache entry A
/api/products?page=2          → cache entry B
/api/products?page=1&_t=12345 → cache entry C (cache-busted!)

That last one is a common mistake — cache-busting query params create new cache entries for identical content. Conversely, if the API returns different content based on the Accept-Language header but the cache key doesn't include it, users get the wrong language.

Most CDNs support custom cache keys. Cloudflare's Cache Rules, for example, allow including/excluding specific query params and headers.

Purge Strategies

Cached content eventually needs to be invalidated. There are three approaches:

TTL-Based Expiry

Set a max-age and let content expire naturally. Simple and reliable, but there's a window where stale content is served. For most use cases, a TTL of 5-60 minutes with stale-while-revalidate is the right trade-off.

On-Demand Purge

Actively remove content from the cache when it changes. CDNs offer different purge capabilities:

CDN	Purge Speed	Purge Types
Fastly	<150ms global	URL, surrogate key, all
Cloudflare	<30s typical	URL, tag, prefix, all
CloudFront	1-10 minutes	URL path pattern, all
Akamai	seconds-minutes	URL, CP code, tag

Surrogate keys (Fastly) / cache tags (Cloudflare) are the most powerful approach: tag every product page with product-123, and when that product updates, purge by tag. This invalidates only the affected content across all PoPs instantly.

Versioned URLs

The most reliable strategy for static assets: include a content hash in the URL.

/static/app.a3b4c5d6.js   → Cache forever (immutable)
/static/app.e7f8g9h0.js   → New deploy = new URL = automatic "invalidation"

This is why build tools generate fingerprinted asset filenames. The HTML referencing these assets has a short TTL, but the assets themselves are cached indefinitely.

Edge Compute: Beyond Caching

Modern CDNs are not just caches — they're distributed compute platforms.

Cloudflare Workers runs JavaScript/Wasm at every PoP with sub-millisecond cold starts. Entire applications can run at the edge:

// Cloudflare Worker: A/B test at the edge
export default {
  async fetch(request) {
    const url = new URL(request.url);
    const bucket = request.headers.get('cf-connecting-ip')
      .split('.').reduce((a, b) => a + parseInt(b), 0) % 100;

    if (bucket < 50) {
      url.pathname = '/variant-a' + url.pathname;
    } else {
      url.pathname = '/variant-b' + url.pathname;
    }
    return fetch(url);
  }
};

This A/B test decision happens in microseconds at the edge, with zero latency to origin. Without edge compute, the alternatives are a server-side decision (adding origin RTT) or a client-side decision (causing layout shift).

Lambda@Edge (AWS) runs Node.js/Python at CloudFront edge locations, typically used for:

• Request rewriting and redirect rules
• Authentication and authorization at the edge
• Dynamic origin selection based on request attributes
• Modifying response headers for security

Production Architecture Patterns

Multi-Origin with Failover

Configure the CDN with a primary and backup origin. If the primary returns 5xx errors or times out, the CDN automatically routes to the backup. This provides origin-level redundancy without client-side logic.

Tiered Caching for APIs

For dynamic API responses that change infrequently:

Cache-Control: public, s-maxage=10, stale-while-revalidate=60

The CDN caches for 10 seconds, and serves stale for up to 60 seconds while fetching fresh content in the background. Users always get a fast response, and the origin sees dramatically less traffic. This pattern works beautifully for product catalogs, search results, and any read-heavy API.

Edge-Side Includes (ESI)

For pages with a mix of static and dynamic content: cache the page shell at the edge and dynamically include fragments. The CDN assembles the final page from cached parts and real-time fragments, reducing origin load while keeping personalized content fresh.

Operational Considerations

Monitoring Cache Effectiveness

Track these metrics:

• Cache hit ratio: Target 85%+ for static content, 50%+ for dynamic. Below this, review cache key design and headers.
• Origin shield hit ratio: Should be 90%+. If not, the shield tier might be misconfigured.
• Bandwidth saved: The delta between edge-served bytes and origin-served bytes. This represents the cost savings.
• Purge latency: How long after a purge until all PoPs serve fresh content. Critical for time-sensitive updates.

Common Debugging Workflow

# Check cache status for a URL
curl -sI https://example.com/page | grep -i "cf-cache-status\|x-cache\|age"

# CF-Cache-Status: HIT     → served from edge cache
# CF-Cache-Status: MISS    → fetched from origin
# CF-Cache-Status: DYNAMIC → not eligible for caching
# Age: 3600                → cached for 3600 seconds

# Verify which PoP served the request
curl -sI https://example.com | grep -i "cf-ray\|x-amz-cf-pop"

CDNs are not magic — they're a well-understood caching layer with clear rules. Get the Cache-Control headers right, design cache keys correctly, and latency drops 10x for the majority of traffic. Miss the fundamentals and the CDN becomes an expensive passthrough.