The Runtime Theory

CDN Request Flow: Edge Hit, Origin Fetch, Revalidate

Trace a request to the nearest edge PoP: cache lookup, origin fetch on miss, TTL-based caching, and revalidation when content goes stale.

The Runtime Theory Team09 stages

trace / request.md

DNS PICKS THENEAREST EDGEEDGE PARSESCACHE RULESLOCAL STOREIS CHECKEDFRESH COPYIS SERVEDREQUEST GOESUPSTREAMORIGIN DOESTHE REAL WORKRESPONSE ISCACHED AND SERVEDSTALE COPIESREVALIDATECYCLE RESTARTS

readyThe client resolves the hostname, and the DNS answer points at the nearest edge PoP — chosen by anycast or DNS-based routing so the request travels to a nearby cache.

A CDN is a caching hierarchy with geography on top. This diagram follows one request: DNS routes it to the nearest edge, the edge checks its store, and either serves a fresh copy or fetches from the origin and caches the result. The two properties that make the whole thing work are locality — the edge is closer to the client than the origin, in network terms — and reuse — most objects are requested many times but change rarely.

The stages are ordered by cost. The cheap decisions come first: the edge lookup costs nothing compared with the origin round trip, so the flow is arranged to succeed there as often as possible. The TTL decides how often a given object must fall through, and revalidation is the middle path: a stale-but-unchanged object refreshes with a conditional request that costs the origin almost nothing. Every cache-control header you set is a stage in this diagram, deciding how long each object skips the origin.