How a CDN Works: Edge Caching, TTLs, and Cache Hit Ratio

Light in fiber crosses the Atlantic in roughly 20 milliseconds each way, and real networks add routing, congestion, and connection setup on top, so a user in Mumbai fetching a file from a server in Virginia waits a substantial fraction of a second before the first byte arrives, no matter how fast the server is. That distance is the floor physics puts under every request; the orders-of-magnitude table is in latency vs throughput.

A CDN (content delivery network) is a geographically distributed network of servers that caches content at edge locations close to users and serves it from the nearest one. The first request for a file travels to your origin server; the CDN stores a copy at its edge, and every later request is answered from nearby, milliseconds away instead of continents away. CDNs exist to delete distance from the latency budget.

How a CDN works: the request path

The machinery has three moving parts; routing users to a nearby edge, deciding whether the content is already there, and fetching it when it is not:

User requests cdn.example.com/image.png
        ↓
DNS / anycast routing    → directed to the nearest edge PoP
        ↓
Edge cache lookup         → hit? serve immediately
        ↓ miss
Origin fetch (via origin shield, in large networks)
        ↓
Edge stores the copy, TTL applies
        ↓
Response served from the edge

Routing works one of two ways. DNS-based CDNs answer the user’s DNS lookup with the address of a nearby edge server, which is why a DNS step appears in the path. Anycast-based CDNs advertise the same IP address from every location, letting internet routing deliver each user to the nearest one. Both aim at the same target: the edge with the shortest network distance to the user.

On a cache miss, the edge fetches from your origin, your real server, wherever the source of truth lives. Large CDNs insert an origin shield between edges and origin: a designated cache layer that collapses misses, so an object newly popular in ten cities triggers one origin request instead of ten.

Edge vs origin

• Edge: the CDN’s servers, in many locations, close to users. They hold cached copies and serve the overwhelming majority of traffic on a well-run site.
• Origin, your infrastructure: the authoritative version of every object. It answers cache misses, receives writes and uploads, and defines the source of truth.

Every CDN configuration decision is a negotiation between the two: serve from the edge (fast, possibly stale) or from the origin (authoritative, slow). TTLs, caching headers, and purge rules all exist to answer that question per URL, and for how long.

What a CDN caches and what it must not

CDNs cache HTTP responses that are safe to reuse, and the safety line is drawn by your origin’s response headers:

• Static assets (images, scripts, stylesheets, fonts, video segments) the classic CDN payload, cacheable under almost any reasonable policy.
• Slowly-changing dynamic responses; API GETs whose content varies on minutes or hours (product details, public profiles) are cacheable when the origin marks them so, with short TTLs.
• Never cache, responses tied to one user or one moment: authenticated pages, anything carrying a Set-Cookie header, POST responses, personalization. The Vary header extends the rule within the cacheable set; a response marked Vary: Accept-Encoding is stored as separate entries per encoding, for instance.

Which responses may be stored, and for how long, is standardized; HTTP caching is defined in RFC 9111, and the two headers that matter most day to day are Cache-Control and Vary.

TTL: how long a copy is trusted

A cached copy has a lifetime: the TTL, assigned by the origin’s Cache-Control header. Cache-Control: max-age=86400 tells the edge it may reuse this response for a day without asking; after expiry, the next request revalidates with the origin. Shared caches like CDN edges are governed by s-maxage when present: a separate, usually shorter policy for the CDN than the one given to a user’s browser. Directives like no-store (never cache) and private (browser only, never a shared cache) pull a URL out of the CDN entirely.

The TTL is a staleness wager: long TTLs maximize hit ratio and minimize origin load, short TTLs keep content fresh at the cost of more origin traffic. Versioned URLs make long TTLs safe, app.4f2a91.js can be cached for a year, because a new build is a new URL, which is why production sites fingerprint their assets and cache them nearly forever.

Cache hit ratio

The cache hit ratio is the share of requests served from the edge without touching the origin. It is the CDN’s defining operational metric, because it converts directly into the two things a CDN sells: latency (edge hits are nearby) and origin load (every miss is a full round trip to your infrastructure).

Four things move the ratio:

• Cacheability. Every response that a personalization header or a stray cookie renders uncacheable is a guaranteed miss. Auditing “why was this a miss” is the standard optimization loop.
• TTL length. A one-minute TTL on a popular object misses constantly; a day-long TTL almost never.
• Cache-key design. Query strings and Vary dimensions multiply cache entries; a response that varies on parameters it does not actually need fragments its own cache.
• Traffic shape. Hit ratio is a popularity contest: long-tail URLs requested rarely will always miss. The ratio that matters is traffic-weighted, not URL-weighted.

For a static-heavy site, the vast majority of requests should be served from the edge. When the ratio sags, the culprits are almost always uncacheable responses or fragmented cache keys, not CDN capacity.

Invalidation and purge

Long TTLs need an escape hatch. The purge API removes copies before expiry, by URL, by cache tag, or globally, and the alternative avoids purging entirely: versioned URLs publish new content under a new name, so nothing needs invalidating and old copies simply expire unused. The failure mode is the purge storm: purging the most popular objects at once converts the next wave of traffic into a synchronized wall of origin fetches. What happens inside your infrastructure after the edge (application-level caching patterns, eviction, and invalidation) is the caching series’ territory, starting with caching in system design.

Push vs pull CDNs

The distinction is who puts content into the CDN:

Nearly every modern web CDN is pull-based: edges fill themselves from the origin as traffic arrives, and nobody uploads anything. Push remains the right tool when assets are known in advance and large (video libraries, game patches, installers) or when the origin must never be surprised by demand for an asset nobody has requested yet.

What a CDN does for dynamic content

Not everything can be cached, but the edge still helps uncacheable traffic: the TCP and TLS handshakes terminate at the nearby edge instead of across a continent, saving round trips on every new connection, and many CDNs route dynamic requests across their own backbone, often a shorter, better-managed path than the public internet between the user and your region. Uncacheable does not mean unaffected; the distance costs less, but it still costs. When the bottleneck is compute at the origin rather than network distance, the fix is load balancing and a bigger fleet, not the CDN.

Failure modes

• Serving stale past an origin outage. An edge that keeps serving expired content while the origin is unreachable is usually the desired behavior (availability over freshness) but it surprises teams that never configured it.
• Purge storms. Purging hot objects at once converts user traffic into an origin flood, at the exact moment someone was probably already nervous about the origin.
• Fragmented cache keys. Randomized query strings (tracking parameters in cacheable URLs) multiply cache entries and crater the hit ratio.
• Origin as the hidden single point of failure. A CDN in front of one origin in one region has the same failure domain as that origin; the edges merely mask it until the first miss.

Cost considerations

CDN economics are egress economics: pricing is built around the volume of bytes delivered, and for traffic-heavy sites, moving those bytes from CDN edges is generally cheaper than serving them all from your own infrastructure. Every point of hit ratio is traffic that never touches your origin, its balancers, or its egress bill, which makes hit ratio a cost lever as much as a performance metric. The cheapest byte is the one your origin never sends.

Common mistakes

• Sending no Cache-Control at all. Origins that send no caching headers leave freshness to cache heuristics, and heuristic staleness is an incident waiting to happen. State the policy explicitly.
• Versionless URLs with long TTLs. app.js cached for a year cannot be updated except by a purge; fingerprint assets so a new build is a new URL.
• Authenticated responses marked cacheable. A personalized page stored at a shared edge and served to a different user is a security incident, not a performance win.
• Optimizing the wrong hit ratio. URL-weighted ratios flatter long-tail misses; the number that pays is traffic-weighted.
• Forgetting the CDN when debugging. “We fixed it, but users still see the old version” is almost always a copy living at the edge with TTL unexpired, check the edge before re-debugging the origin.

FAQ

How does a CDN work?

A user’s request is routed to the CDN edge server nearest them, via DNS or anycast. If the edge has a cached copy (a cache hit), it responds immediately; on a miss, it fetches from your origin server, stores the copy, and serves it. Later requests for the same content are answered from the edge, milliseconds from the user instead of a continent away.

What is the difference between edge and origin?

Edge servers are the CDN’s machines, distributed in many locations close to users, holding cached copies. The origin is your infrastructure, the authoritative source of every object. Edges serve traffic; origins answer misses and hold the source of truth.

What is a good cache hit ratio?

For a static-heavy site, the vast majority of requests should be served from the edge; the exact number depends on traffic mix. The number to watch is traffic-weighted: what share of your bytes never reach the origin. A sagging ratio points at uncacheable responses or fragmented cache keys, not CDN capacity.

What is a push vs pull CDN?

A pull CDN fetches content from your origin on first request: the modern default, with no upload step. A push CDN requires you to upload assets explicitly, and suits large, known-in-advance content like media libraries and software distribution, where the first request must not be a miss.

What is a CDN TTL?

The lifetime a cached copy is trusted before the edge revalidates it with the origin, set by the response’s Cache-Control header: max-age for browsers, s-maxage for shared caches like CDN edges. Long TTLs raise hit ratio and staleness risk together; versioned URLs let you keep TTLs long without staleness mattering.

Does a CDN help with dynamic content?

Indirectly, yes. Uncacheable responses still benefit from terminating TCP and TLS at a nearby edge and, on many CDNs, from routing across the provider’s backbone. But dynamic content’s real constraints (compute and data locality at origin) are solved by scaling your origin, not by the CDN.

Related articles

• Next read: caching in system design, the application-level counterpart: patterns, eviction, and hit ratio inside your infrastructure.
• latency vs throughput; the numbers a CDN moves.
• reverse proxy explained, the single-site front door; the CDN is the same idea at planetary scale.
• load balancing in system design, what sits behind the CDN at the origin.
• API gateway in system design, the next hop on the path for dynamic traffic.

Last updated on 16 September 2026