Why architecture matters here
CDN architecture matters because it's essential to serving content globally with low latency and to protecting the origin -- a foundational component of virtually every large-scale web service. Serving content from a single origin to global users is slow (distant users suffering the latency of round trips to the far origin) and unscalable (the origin bearing all the load -- a bottleneck and a single point of failure). A CDN solves both: low latency (content served from edge PoPs near users -- short round trips) and origin offload (most requests served by the edge cache -- protecting the origin from the load, and from traffic spikes and DDoS). This is essential for any global-scale web service (websites, apps, streaming, downloads -- all benefit from CDN delivery) -- so CDNs are a foundational component (virtually every large web service uses a CDN). And CDNs increasingly do more (dynamic acceleration, edge compute, security) -- becoming a broader edge platform. For anyone building or operating web-scale services, understanding CDN architecture (edge caching, origin offload, the caching mechanics) is essential, and the CDN is often the first line of both performance (edge delivery) and defense (edge security).
The edge-caching-plus-origin-offload insight is the architectural core, and it's the essence of what a CDN does. The CDN places edge PoPs near users (globally distributed) that cache the content. When a user requests content, they're routed to the nearest edge (via anycast -- the network routing to the closest PoP), which checks its cache: a cache hit (the content cached at the edge) is served immediately from the edge (fast -- near the user, no trip to the origin) -- providing the low latency (edge delivery) and offloading the origin (the request served by the edge, not the origin). A cache miss (the content not cached) fetches from the origin (or a higher cache tier), caches it at the edge (for subsequent requests), and serves it. So the more requests are cache hits (served from the edge -- the cache hit ratio), the better: more low-latency edge delivery (users served fast from the edge) and more origin offload (fewer requests reaching the origin). This -- edge caching (content cached near users, served fast on hits) providing low latency and origin offload (the origin protected from the load) -- is the essence of the CDN, and the cache hit ratio (maximizing edge hits) is the core measure of its effectiveness. Understanding the edge-caching-plus-origin-offload core (and the cache hit ratio as its measure) is understanding what a CDN fundamentally does.
And the caching-mechanics reality (keys, TTL, invalidation, hierarchy) is what determines the CDN's effectiveness and correctness. The CDN's value depends on caching effectively (high hit ratio) and correctly (serving fresh, correct content). Cache keys: what identifies a cached object (typically the URL, possibly plus headers -- e.g., varying by language or device) -- the key determining what's a hit (a request matching a cached object's key) -- so the key design affects the hit ratio (too granular keys -- e.g., varying by too many headers -- fragment the cache, lowering the hit ratio; the right key granularity maximizes hits). TTL: how long content is cached (the time-to-live -- after which the edge re-validates or re-fetches) -- balancing freshness (shorter TTL -- fresher, but more origin fetches -- lower hit ratio) against offload (longer TTL -- more hits, but staler). Invalidation and purge: updating cached content when the origin changes (invalidating or purging the cached copies -- so users get the updated content, not stale cache) -- correctness (serving fresh content after updates). Cache hierarchy: edge PoPs backed by shield/mid-tier caches backed by the origin -- so an edge miss checks a shield (a mid-tier cache) before the origin (further offloading the origin -- many edge misses served by the shield, not reaching the origin) -- improving the offload (a hit at any tier avoids the origin). These caching mechanics (keys and TTL for the hit ratio, invalidation for correctness, the hierarchy for offload) determine the CDN's effectiveness (hit ratio, offload) and correctness (fresh content) -- and understanding them is understanding how to operate a CDN effectively (maximizing the hit ratio and offload while serving fresh content).
The architecture: every piece explained
Top row: the edge and delivery. Edge PoPs: servers distributed globally, near users (points of presence -- the edge of the network, close to users) -- caching and serving content near users. Anycast routing: users routed to the nearest edge (typically via anycast -- the same IP announced from all PoPs, the network routing each user to the closest PoP) -- so each user reaches a nearby edge. Edge caching: the edge serves content from its cache (a cache hit -- fast, near the user, no origin trip) -- the low-latency edge delivery. Origin offload: most requests served by the edge cache (not reaching the origin) -- protecting the origin (from the load, spikes, DDoS) -- the offload.
Middle row: the caching mechanics. Cache keys and TTL: the cache key (what identifies a cached object -- typically the URL plus varying headers) and TTL (how long it's cached) -- determining what's a hit and the freshness/offload balance. Invalidation and purge: updating or removing cached content when the origin changes (invalidating/purging -- so users get fresh content after updates) -- cache correctness. Cache hierarchy: edge PoPs backed by shield/mid-tier caches backed by the origin (edge miss -> shield -> origin) -- so an edge miss checks a shield before the origin (further offloading the origin). Dynamic and edge compute: beyond static content -- dynamic content acceleration (optimizing dynamic/personalized content delivery) and edge compute (running code at the edge -- for logic, personalization, transformation near the user) -- the CDN as a broader edge platform.
Bottom rows: security and the metric. TLS and security at the edge: the edge as a security perimeter -- TLS termination (terminating HTTPS at the edge), DDoS mitigation (absorbing/filtering attack traffic at the edge -- the distributed edge capacity absorbing DDoS), WAF (web application firewall -- filtering malicious requests at the edge) -- the edge providing security. Cache hit ratio: the core metric -- the fraction of requests served from cache (hits) vs fetched from the origin (misses) -- a high hit ratio meaning good latency (edge delivery) and offload (origin protected); the key measure of CDN effectiveness. The ops strip: cache policy (the caching configuration -- keys, TTLs, what's cacheable -- tuned for the hit ratio and correctness), hit ratio (monitoring and maximizing the cache hit ratio -- the core metric; a low hit ratio indicating poor caching -- keys too granular, TTLs too short, cacheable content not cached), and purge (managing invalidation/purge -- updating cached content correctly and promptly when the origin changes).
End-to-end flow
Trace a request through the CDN. A user in a distant region requests an image. Anycast routes them to the nearest edge PoP (the closest to them -- low latency). The edge checks its cache: a cache hit (the image cached at the edge -- from a prior request) -- so the edge serves the image immediately (fast -- near the user, no trip to the distant origin) -- low latency, and the origin not touched (offloaded). For a cache miss (the image not cached at this edge -- e.g., first request in this region): the edge checks the cache hierarchy (a shield/mid-tier cache -- if the image is there, served from the shield, still offloading the origin; else) fetches from the origin, caches the image at the edge (and shield -- for subsequent requests), and serves it. So the first request populates the edge cache (a miss -- fetching from the origin/shield), and subsequent requests hit the edge cache (fast, offloading the origin). The edge caching (serving from the edge on hits) provides the low latency (near the user) and origin offload (the origin touched only on misses -- most requests hitting the edge cache) -- the CDN's core delivery.
The invalidation and hierarchy vignettes show correctness and offload. An invalidation case: the origin updates the image (a new version). But the edges have the old version cached (until the TTL expires -- serving stale content). To serve the fresh version promptly, the team purges the image (invalidating the cached copies across the edges -- so the next request re-fetches the fresh version from the origin and re-caches it) -- ensuring the fresh content is served (correctness -- the invalidation updating the cache after the origin change). A hierarchy case: many edges get a cache miss for a newly-popular object (not yet cached at most edges) -- without a hierarchy, all these edge misses would hit the origin (a load spike on the origin). With the cache hierarchy (a shield tier), the edge misses check the shield first -- the first edge miss fetches from the origin and populates the shield, and the subsequent edge misses hit the shield (not the origin) -- so the origin sees just one fetch (the shield absorbing the other edge misses) -- the hierarchy further offloading the origin (the shield absorbing the edge misses).
The security and hit-ratio vignettes complete it. A security case: the service is hit by a DDoS attack (a flood of traffic). The CDN's edge absorbs and mitigates it (the distributed edge capacity absorbing the attack traffic, filtering it -- the origin protected behind the edge) -- the edge providing DDoS protection (the origin shielded from the attack by the CDN edge). And the edge terminates TLS (HTTPS terminated at the edge near the user -- faster TLS handshakes) and runs a WAF (filtering malicious requests at the edge) -- the edge as a security perimeter. A hit-ratio case: the team monitors the cache hit ratio (the core metric) -- noticing a lower-than-expected ratio, they investigate (finding the cache keys too granular -- varying by an unnecessary header, fragmenting the cache -- lowering the hit ratio) -- fixing the key (removing the unnecessary variation) -- raising the hit ratio (more hits -- better latency and offload). The consolidated discipline the team documents: use a CDN for global content delivery (edge PoPs near users, anycast routing -- low latency) and origin offload (edge caching protecting the origin), maximize the cache hit ratio (the core metric -- via good cache keys, appropriate TTLs, caching cacheable content), manage invalidation/purge (serving fresh content after origin changes -- correctness), use the cache hierarchy (shield tiers further offloading the origin), leverage the edge for security (TLS termination, DDoS mitigation, WAF -- the edge perimeter), consider edge compute for dynamic/logic needs, and monitor the hit ratio and offload -- because the CDN serves content close to the user (edge caching -- low latency) and offloads/protects the origin (edge cache absorbing the load, the edge providing security), foundational to global web-scale services, with the cache hit ratio the core measure of its effectiveness.