Content Delivery Network (CDN) and Edge Computing

Definition: A Content Delivery Network is a globally distributed network of proxy servers that cache content close to users to minimize latency, and Edge Computing extends that same distributed footprint with the ability to execute lightweight code at those same locations rather than only serving cached bytes. CDNs originated in the late 1990s — Akamai, founded in 1998 out of MIT research, was the pioneer — purely to solve the physics problem of serving static files faster than a single origin server thousands of miles from some users ever could. Edge computing is the newer half of the idea, roughly 2017 onward, once providers realized those same globally distributed Points of Presence (PoPs) could also run actual application logic, not just cache and serve files.

How It Works

CDNs cache static assets (HTML, CSS, JS, images, video) at Points of Presence (PoPs) worldwide; when a user requests a file, it’s served from the geographically closest PoP rather than the origin server, often over a connection that’s already been optimized for the “last mile” to that region
Cache behavior is governed by HTTP cache-control headers (max-age, s-maxage, stale-while-revalidate) set by the origin, or by explicit rules configured on the CDN itself, determining how long an edge server serves a cached copy before checking back with origin
Cache invalidation happens either passively (the cached copy simply expires per its TTL) or actively via an explicit purge API call, which is the mechanism a deploy pipeline uses to force fresh content out immediately after a release
Edge Computing runs serverless functions directly on CDN nodes (Cloudflare Workers, Vercel Edge Functions, Fastly Compute), intercepting and modifying requests or responses — rewriting a URL, personalizing content, running A/B test logic, or authenticating a request — before it ever reaches the cache layer or origin
Origin shielding designates one PoP as an intermediate cache layer between edge nodes and the true origin, so a cache miss at dozens of edge locations doesn’t turn into dozens of simultaneous requests hammering the origin server at once
Anycast routing lets many physically distinct PoPs share the same IP address, with network-level routing (BGP) sending each user’s request to the topologically nearest one automatically, without any DNS-level geo-logic required
TLS termination at the edge means the encrypted connection ends at the nearest PoP rather than at origin, shortening the expensive handshake round trip and letting the CDN also absorb the CPU cost of encryption/decryption on origin’s behalf

Why It Matters

Drastically reduces load times for users far from the origin server, since physical distance and the number of network hops directly translate into latency that no amount of server-side optimization alone can remove
Decreases bandwidth and compute load on the origin server, since a well-cached site might serve the overwhelming majority of requests entirely from edge caches without the origin ever seeing them
Provides a substantial buffer against DDoS attacks, since a CDN’s distributed capacity absorbs and filters malicious traffic before it reaches — or overwhelms — the actual origin infrastructure
Edge computing shrinks the distance between “request arrives” and “logic runs” to near-zero for latency-sensitive personalization, auth checks, or redirects, avoiding a round trip to a origin server or centralized Serverless Computing and Cold Starts region entirely
For global products, a CDN is often what makes a single-region origin viable at all — instead of standing up infrastructure in every region a user base spans, most read-heavy traffic never needs to reach origin regardless of where it’s deployed

Under the Hood: Cache Keys and the Hit/Miss Path

Every cached response at a CDN edge is stored and looked up by a cache key, which by default is usually the full request URL but can be customized to include specific headers, cookies, or query parameters — get the cache key wrong and two genuinely different responses (say, a page rendered differently per user, or per Accept-Language) collapse into one cached entry that gets served to the wrong audience, a bug class known as cache poisoning by key confusion. When a request arrives at an edge PoP, the CDN computes that request’s cache key and checks local storage: a cache hit returns the stored response immediately, often in single-digit milliseconds, with no origin contact at all; a cache miss triggers a request to origin (or to a shield PoP first), stores the response according to its cache-control headers, and serves it onward — meaning the very first user to request a given URL in a given region always pays the full origin round-trip, while every subsequent user in that region benefits from the now-warm cache until it expires or gets purged.

Comparison: CDN/Edge vs Origin-Only Serving vs Simple Reverse-Proxy Caching

	CDN/Edge Computing	Origin-Only Serving	Simple Reverse-Proxy Caching
Geographic distribution	Global, dozens to hundreds of PoPs	Single region (or a few)	Single location, near origin
Latency for distant users	Low — served from nearest PoP	High — full round trip to origin	High — still one hop from origin
DDoS resilience	High — absorbs traffic at the edge	Low — origin bears full load	Low — proxy itself can be overwhelmed
Code execution at the cache layer	Yes, on modern edge platforms	N/A	Rarely, usually cache-only (Reverse Proxy logic at best)
Operational complexity	Moderate — cache keys, invalidation, edge logic	Low, but doesn’t scale geographically	Low
Cost model	Pay for bandwidth/requests, often cheaper than equivalent origin egress	Origin bandwidth and compute scale with all traffic	Origin bandwidth reduced only for cached routes

Common Pitfalls

Setting aggressive cache headers without a robust invalidation strategy, causing users to see stale data — or worse, a stale version of a page referencing assets that no longer exist — after a new deployment
Getting the cache key wrong (caching per-user or per-locale content under a shared key), silently serving one user’s personalized or region-specific response to a completely different user
Caching responses that set cookies or contain authentication tokens, leaking one user’s session data to whoever else’s request happens to hit that same cached entry
Treating edge functions as a place for heavy computation or database calls, when their real value is lightweight, latency-sensitive logic — pushing significant compute or data access to the edge often just relocates a bottleneck rather than fixing it
Forgetting that a CDN purge isn’t instantaneous everywhere at once — different PoPs propagate a purge on different timelines, so “stale content for a few seconds/minutes after purge” is often expected behavior, not a bug
Relying on the CDN as the only cache invalidation mechanism while application-level caches (Caching at the database or app layer) remain out of sync, so a purge at the edge doesn’t guarantee genuinely fresh data end to end
Assuming edge function execution environments behave identically to a normal server runtime — many edge platforms run a restricted JS runtime (no full Node.js APIs, tight CPU/memory limits, no persistent local disk), and code that works locally can fail or throttle unexpectedly at the edge

Code Example

# Origin response instructing the CDN how long to cache, and how to behave on expiry
HTTP/1.1 200 OK
Cache-Control: public, max-age=300, s-maxage=3600, stale-while-revalidate=60
ETag: "a1b2c3d4"

// A minimal edge function (Cloudflare Workers-style) rewriting a request
// before it reaches cache or origin — runs at every nearby PoP, not one region
export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === "/old-page") {
      return Response.redirect(url.origin + "/new-page", 301);
    }
    return fetch(request); // pass through to cache/origin unchanged
  },
};

Best Practices

Set explicit, deliberate Cache-Control headers on every response instead of relying on a CDN’s default caching behavior, which varies by provider and content type
Use stale-while-revalidate for content where briefly-stale is acceptable, letting the CDN serve a cached copy instantly while it refreshes in the background rather than making one unlucky user wait on a cache miss
Never cache responses containing authentication tokens, session cookies, or per-user personalization under a cache key that doesn’t account for the user, and explicitly mark such responses as private/no-store when appropriate
Trigger active purges from the deploy pipeline for assets that must be fresh immediately, rather than relying solely on passive TTL expiry
Keep edge functions lightweight and latency-focused (redirects, auth checks, header rewrites, simple personalization) rather than pushing heavy business logic or database access into them
Monitor cache hit ratio as a first-class metric, since a low hit ratio on content that should be highly cacheable is often the clearest early signal that cache keys or headers are misconfigured

FAQ

Is a CDN the same thing as edge computing? Not exactly — a CDN’s original job is caching and serving content from distributed locations, while edge computing extends the same distributed footprint to running actual application code, modern CDN providers now offer both under one platform.

How fast does content propagate to all PoPs after a purge? It varies by provider, often seconds to a couple of minutes globally, which is why content that must be perfectly consistent everywhere the instant it changes needs a design that accounts for that propagation delay rather than assuming instantaneous global consistency.

Can a CDN cache API responses, not just static assets? Yes, provided the API response is cacheable (same response for the same request, or acceptably stale for a short window) and carries appropriate cache-control headers — this is increasingly common for read-heavy, rarely-changing API endpoints.

Do edge functions replace the need for an origin server? Not usually — most applications still need a full origin (or a set of backend services) for anything stateful, data-heavy, or requiring a full runtime, edge functions are best understood as a thin, fast layer in front of that origin rather than a wholesale replacement for it.

Why does a page sometimes look different right after a deploy, then update a moment later? That’s usually cache propagation lag — different PoPs around the world purge and re-fetch on slightly different timelines, so users in different regions can briefly see different versions of the same page until every edge location has caught up.

History

Akamai, founded in 1998 out of MIT research on distributed systems, pioneered the CDN model to solve the physics of serving content quickly to a geographically spread-out internet audience
Cloud and video-streaming growth through the 2000s and 2010s (YouTube, Netflix) drove massive CDN capacity buildout, since video is both bandwidth-heavy and extremely latency-sensitive to buffer
Cloudflare’s 2017 launch of Workers marked a turning point, popularizing genuinely programmable edge compute rather than pure caching, with Fastly and Vercel following with their own edge-function platforms shortly after
Edge computing has since expanded beyond pure web serving into IoT and real-time applications, running logic physically close to devices or users when even a round trip to a nearby cloud region is too slow
The 2020s saw edge platforms add lightweight data stores (Cloudflare KV/D1, Vercel Edge Config) alongside compute, extending the model from purely stateless request handling toward genuinely stateful edge applications

Example

Cloudflare and Vercel use globally distributed edge networks to serve frontend web assets almost instantly to users worldwide, while Cloudflare Workers execute JavaScript directly at the edge — for example, checking a request’s auth cookie and redirecting unauthenticated users before the request ever reaches origin, saving a full round trip for a check that never needed the origin server in the first place.

Referenced by

Dig deeper

Spot an error in this note?