CDNs and Edge Computing

Terminology

• CDN (Content Delivery Network): a geographically distributed network of servers that caches and serves content from locations close to end users, reducing latency and origin server load
• Edge server (Point of Presence, PoP): a CDN server located in a data center near end users that caches content and serves requests without contacting the origin
• Origin server: the authoritative source of content that the CDN pulls from when a requested resource is not cached at the edge
• Cache hit (edge hit): a request served directly from the edge server's cache without contacting the origin
• Cache miss: a request where the edge server does not have the content cached and must fetch it from the origin or a mid-tier cache
• TTL (Time to Live): the duration for which a cached resource is considered fresh; after expiry, the edge must revalidate or refetch from the origin
• Cache invalidation (purge): the process of removing or marking cached content as stale before its TTL expires, typically triggered when the origin content changes
• Cache hierarchy (tiered caching): a multi-level cache architecture where edge servers check a regional mid-tier cache before going to the origin, reducing origin load
• Pull-based CDN: a CDN model where edge servers fetch content from the origin on the first request (cache miss) and cache it for subsequent requests
• Push-based CDN: a CDN model where the origin proactively uploads content to edge servers before any user requests it
• Edge function: a lightweight serverless function that runs at CDN edge locations, enabling custom logic (authentication, A/B testing, personalization) close to the user
• Anycast: a network routing technique where the same IP address is announced from multiple locations; routers direct each request to the nearest location based on network topology
• Stale-while-revalidate: a caching strategy where the edge serves a stale cached response immediately while fetching a fresh copy from the origin in the background
• Origin shield: a designated mid-tier cache that consolidates all edge requests to the origin through a single point, reducing origin load during cache misses

What & Why

The speed of light is a hard limit. A request from Tokyo to a server in Virginia takes at least 70 milliseconds for the round trip, just from the physics of signal propagation through fiber optic cables. Add DNS resolution, TCP handshake, TLS negotiation, and server processing, and a single page load can take hundreds of milliseconds or more.

CDNs solve this by placing copies of content on servers distributed around the world. When a user in Tokyo requests an image, the CDN serves it from a server in Tokyo (or nearby), not from Virginia. The round-trip time drops from 70ms to 2-5ms. For static assets like images, CSS, JavaScript, and video, this is transformative.

Beyond latency, CDNs provide three other benefits. First, they absorb traffic. A viral blog post or product launch can generate millions of requests per second. The CDN's distributed edge servers handle this load, and the origin server sees only cache misses. Second, they improve availability. If the origin goes down, the CDN continues serving cached content (depending on TTL settings). Third, they provide DDoS protection. The CDN's massive distributed capacity can absorb volumetric attacks that would overwhelm a single origin.

Modern CDNs go beyond static content caching. Edge functions allow running custom code at edge locations: authentication checks, A/B test routing, header manipulation, image resizing, and even full API responses. This moves computation closer to users, reducing latency for dynamic content that traditionally required a round trip to the origin.

The main challenge with CDNs is cache consistency. When content changes at the origin, cached copies at hundreds of edge locations become stale. Cache invalidation (purging) must propagate globally, which takes time. Strategies like short TTLs, stale-while-revalidate, and versioned URLs help manage this trade-off between freshness and performance.

How It Works

CDN Request Flow

1. The user's DNS query resolves to the nearest edge PoP via anycast routing.
2. The edge server checks its local cache. On a hit, it returns the content immediately (2-5ms latency).
3. On a miss, the edge checks the mid-tier regional cache. If the mid-tier has it, the edge caches a copy and returns it.
4. If the mid-tier also misses, the request goes to the origin server. The response flows back through the mid-tier and edge, with each tier caching a copy.

Cache Hierarchy

A two-tier cache hierarchy (edge + mid-tier) dramatically reduces origin load. Without a mid-tier, every cache miss at every edge PoP hits the origin directly. With 200 edge PoPs and a cold cache, the origin could receive 200 simultaneous requests for the same resource. A mid-tier (origin shield) consolidates these into a single origin request.

Edge Functions

Edge functions run at CDN edge locations, executing custom logic before or instead of fetching from the origin:

• Authentication: validate JWT tokens at the edge, rejecting unauthorized requests before they reach the origin.
• A/B testing: route users to different content variants based on cookies or headers, without origin involvement.
• Image optimization: resize and format images on the fly at the edge based on the client's device and connection speed.
• Geolocation routing: serve different content based on the user's country or region.
• API responses: generate simple API responses entirely at the edge for low-latency endpoints.

Cache Invalidation Strategies

TTL-based: set a time-to-live on each cached resource. After expiry, the edge revalidates with the origin. Simple but allows staleness up to the TTL duration.

Versioned URLs: append a version hash to the URL (e.g., style.a3f2b1.css). When content changes, the URL changes, so the old cached version is never requested again. The most reliable strategy for static assets.

Purge API: the origin sends a purge request to the CDN when content changes. The CDN invalidates the resource across all edge locations. Propagation takes seconds to minutes depending on the CDN.

Stale-while-revalidate: the edge serves the stale cached version immediately and fetches a fresh copy in the background. The user gets fast responses, and the cache is updated for the next request.

Complexity Analysis

Let $e$ be the number of edge PoPs, $h$ be the cache hit rate, and $n$ be the total requests per second.

With a 95% cache hit rate, the origin handles only 5% of total traffic:

For a site receiving 100,000 requests per second, the origin sees only 5,000 requests per second. The CDN absorbs the other 95,000.

The latency improvement depends on the distance saved. For a user 5,000 km from the origin but 50 km from the nearest edge:

Implementation

ALGORITHM CDNEdgeHandler(request, localCache, midTierCache, origin)
INPUT: incoming HTTP request, local edge cache, mid-tier cache, origin server
OUTPUT: HTTP response
BEGIN
  cacheKey <- GENERATE_CACHE_KEY(request.url, request.headers)

  // Check local edge cache
  entry <- localCache.GET(cacheKey)
  IF entry IS NOT NIL AND NOT EXPIRED(entry) THEN
    RETURN entry.response  // edge hit
  END IF

  // Stale-while-revalidate: serve stale, refresh in background
  IF entry IS NOT NIL AND entry.staleWhileRevalidate THEN
    ASYNC_REFRESH(cacheKey, midTierCache, origin, localCache)
    RETURN entry.response  // serve stale immediately
  END IF

  // Check mid-tier cache
  response <- midTierCache.GET(cacheKey)
  IF response IS NOT NIL THEN
    localCache.PUT(cacheKey, response, TTL: response.cacheControl.maxAge)
    RETURN response  // mid-tier hit
  END IF

  // Fetch from origin
  response <- origin.FETCH(request)
  midTierCache.PUT(cacheKey, response, TTL: response.cacheControl.maxAge)
  localCache.PUT(cacheKey, response, TTL: response.cacheControl.maxAge)
  RETURN response  // origin fetch
END


ALGORITHM CachePurge(cdnController, resourcePattern, edgeNodes)
INPUT: CDN control plane, URL pattern to purge, list of all edge PoPs
OUTPUT: purge confirmation
BEGIN
  purgeId <- GENERATE_UNIQUE_ID()
  acknowledged <- 0

  FOR EACH edge IN edgeNodes DO (in parallel)
    result <- SEND_PURGE_COMMAND(edge, resourcePattern, purgeId)
    IF result IS success THEN
      acknowledged <- acknowledged + 1
    ELSE
      LOG_WARNING("Purge failed at " + edge.location)
      RETRY_PURGE(edge, resourcePattern, purgeId)
    END IF
  END FOR

  RETURN { purgeId: purgeId, acknowledged: acknowledged, total: LENGTH(edgeNodes) }
END


ALGORITHM AnycastRouting(clientIP, edgeLocations)
INPUT: client IP address, list of edge PoP locations with coordinates
OUTPUT: nearest edge PoP
BEGIN
  clientLocation <- GEOIP_LOOKUP(clientIP)
  bestEdge <- NIL
  bestDistance <- INFINITY

  FOR EACH edge IN edgeLocations DO
    distance <- HAVERSINE(clientLocation, edge.coordinates)
    IF distance < bestDistance THEN
      bestDistance <- distance
      bestEdge <- edge
    END IF
  END FOR

  RETURN bestEdge
END


ALGORITHM EdgeFunction(request, config)
INPUT: incoming request, edge function configuration
OUTPUT: response (either generated at edge or proxied to origin)
BEGIN
  // Authentication check at edge
  IF config.requireAuth THEN
    token <- EXTRACT_TOKEN(request)
    IF NOT VALIDATE_TOKEN_AT_EDGE(token) THEN
      RETURN 401 Unauthorized
    END IF
  END IF

  // A/B test routing
  IF config.abTest IS NOT NIL THEN
    variant <- DETERMINE_VARIANT(request.cookies, config.abTest)
    request.headers["X-Variant"] <- variant
  END IF

  // Geolocation-based routing
  IF config.geoRoute IS NOT NIL THEN
    country <- GEOIP_COUNTRY(request.clientIP)
    targetOrigin <- config.geoRoute[country] OR config.geoRoute["default"]
    RETURN PROXY(request, targetOrigin)
  END IF

  RETURN PROXY(request, config.defaultOrigin)
END

Real-World Applications

• Static website hosting: blogs, documentation sites, and marketing pages serve HTML, CSS, JavaScript, and images entirely from CDN edge servers, achieving sub-10ms load times globally
• Video streaming: platforms cache video segments at edge locations so users stream from nearby servers; adaptive bitrate streaming adjusts quality based on the connection between the user and the edge
• E-commerce: product images, catalog pages, and JavaScript bundles are cached at the edge; during flash sales, the CDN absorbs traffic spikes that would overwhelm origin servers
• Software distribution: operating system updates, game patches, and app downloads are distributed through CDNs to handle massive concurrent download volumes without overloading origin infrastructure
• API acceleration: edge functions handle authentication, rate limiting, and simple API responses at the edge, reducing round trips to origin data centers for latency-sensitive endpoints
• Security and DDoS protection: CDNs absorb volumetric DDoS attacks across their distributed infrastructure, filtering malicious traffic at the edge before it reaches the origin

Key Takeaways

• CDNs reduce latency by serving content from edge servers near users instead of distant origin servers, turning 50-100ms round trips into 1-5ms responses
• Cache hierarchies (edge + mid-tier + origin) prevent cache miss stampedes: the mid-tier consolidates edge misses so the origin sees minimal traffic even with hundreds of PoPs
• A 95% cache hit rate means the origin handles only 5% of total traffic, enabling a modest origin to serve massive global audiences
• Cache invalidation strategies trade freshness for simplicity: versioned URLs are the most reliable for static assets, TTL-based expiry is simplest, and purge APIs provide on-demand control
• Edge functions extend CDNs beyond caching into computation, running authentication, routing, and personalization logic at the edge for lower latency on dynamic requests