Skip to content

PATTERN Cited by 3 sources

CDN edge cache over central origin

Definition

The CDN pattern: keep the authoritative copy of content in a single region (the origin), and replicate read-hot copies into edge caches at geographically-distributed points of presence. Client requests route to the nearest-PoP edge cache first; only on miss does the edge fetch from origin. The origin remains the source of truth; edges are ephemeral, invalidateable read replicas.

This is the geographic-tier instance of the foundational caching pattern — fast+small (edge, per-PoP RAM/SSD) in front of slow+large (origin, central region).

Why the pattern exists

Ben Dicken's framing (Source: sources/2025-07-08-planetscale-caching):

Physical distance on a planet-scale is another interesting consideration for caching. Like it or not, we live on a big spinning rock 25,000 miles in circumference, and we are limited by "physics" for how fast data can move from point A to B.

Concrete latency stratification from a US east-coast origin:

  • East-coast US clients: ~10–20 ms.
  • West-coast US clients: ~50–100 ms.
  • Other-side-of-the-world clients: 250+ ms.

Speed-of-light + router-hop latency are bounded below by physics. No amount of origin optimisation can beat "serve the bytes from 50 km away instead of 5,000 km away".

Architecture

Client (region A) ──> Nearest-PoP edge cache (region A) ──miss──> Origin (region X)
                                                   ↑cache-populate
                                  ──hit──> [bytes from local cache, 10 ms]

Client (region B) ──> Nearest-PoP edge cache (region B) ──miss──> Origin (region X)
                                  ──hit──> [bytes from local cache, 15 ms]

From the Dicken post:

With CDNs we still have a single source-of-truth for the data, but we add data caches in multiple locations around the world. Data requests are sent to the geographically- nearest cache. If the cache does not have the needed data, only then does it request it from the core source of truth.

Full replication vs on-demand population

Two common configurations:

  • On-demand (classic CDN) — edge caches start empty; populate on first miss. Cold objects are slow, hot objects become fast; eviction via LRU/TTL. Amazon CloudFront default, Cloudflare cache default.
  • Full-mirror (rare) — every edge pre-populates every object. Dicken notes: "if the data never changes, we can avoid cache misses entirely! The only time we would need to get them is when the original data is modified." Used for small static catalogues (software package mirrors, root DNS) where the working set fits at every PoP.

Where the pattern matters

  • Image/video delivery — bytes are big, users are everywhere, contents are mostly static. Canonical CloudFront + S3 shape.
  • Static site acceleration — HTML/CSS/JS at every edge.
  • API caching — short-TTL read API responses edge-cached.
  • TLS termination + HTTP/3 — edges handle the round-trip-heavy TLS handshakes close to users.
  • DDoS absorption — edge PoPs absorb volumetric attacks before they reach origin.

Known limitations

  • Invalidation is hard. Purging N edge caches atomically is a hard distributed-system problem; most CDNs offer either "purge by URL list" (slow, not atomic) or tag-based purge (faster but requires tagging discipline).
  • Write path stays at origin. Writes must reach the origin region; the cross-region RTT penalty is not avoidable. This is exactly what Tigris criticised — "CloudFront optimises the read side of a single-write-region bucket", not the write side.
  • Cache variants explode on personalisation. URL + cookie + user-language + A/B-bucket all fork the cache key; naive personalisation can reduce edge hit rate to near-zero. See concepts/cache-variant-explosion.
  • Dynamic content with low TTL / high cardinality — edge caches work best for content that's popular enough to justify the storage at every PoP.
  • Geographic unfairness — origin-close clients see near- no improvement; origin-far clients see the biggest win. Works against global services with an origin-biased user base.

Contrast with globally-distributed origin

Some systems skip the central-origin constraint and distribute writes too — multi-master object stores like Tigris, globally-replicated databases like Spanner / CockroachDB, or region-anycast services (concepts/anycast). These avoid the CDN-over-central-origin shape entirely — there is no "origin region." The trade-off is write-path complexity (cross-region consensus or CRDT-style merge) which classic CDN deployments sidestep by keeping the write path simple.

Seen in

Last updated · 319 distilled / 1,201 read