How a CDN Works

The three layers in a CDN request

Every request through a CDN goes through three layers:

1. Routing layer. Decides which CDN data center (POP) handles this user. Usually via anycast IP — the same IP advertised from every POP, and BGP picks the closest one.
2. Edge cache. The POP checks its local cache for a fresh copy of the requested URL. Hit: serve directly. Miss: go to step 3.
3. Origin fetch. The edge contacts your origin server, retrieves the content, stores it in cache, and forwards to the user.

For repeated requests within the cache TTL, steps 2 and 3 collapse into a single fast cache lookup. The user gets the content with one TCP round-trip to a nearby POP, instead of multiple round-trips across continents to origin.

Points of Presence (POPs)

A POP is a physical facility where the CDN runs edge servers. Major CDNs run hundreds of POPs:

More POPs do not automatically mean better performance. POPs must be on the path of relevant users and well-peered with their ISPs. Fastly's small-POP/big-POP architecture often beats more spread-out networks because each POP is in a top-tier interconnection facility with rich peering.

How users get routed to a POP

Two common mechanisms (covered in detail in anycast vs GeoDNS):

Anycast routing (Cloudflare, Fastly, Google Cloud CDN)

The CDN announces the same IP address from every POP. BGP — the internet's routing protocol — picks the topologically closest POP for each user based on AS path length and ISP routing policies. The user has no idea their packets are going to different POPs based on their network location.

DNS-based / GeoDNS (AWS CloudFront, Akamai, traditional CDNs)

The CDN returns a different IP per region in DNS responses. A user in Tokyo asking for www.example.com gets a different IP than a user in Frankfurt. The mapping is based on the resolver IP geolocation, not the user IP directly — which is why some users see suboptimal routing if they use a public resolver in another region.

The cache decision: hit, miss, pass

When a request arrives at a POP, the edge server consults its cache:

The cache key — what the CDN uses to decide whether two requests are the same content — defaults to the URL and Host header. Most CDNs let you customize the cache key to include query parameters, headers, or cookies (necessary for proper caching of API responses or geo-personalized content).

Origin shielding: a second cache layer

Without shielding, every POP that has a cache miss contacts origin independently. If your origin is in us-east-1 and a cold piece of content suddenly goes viral, you might get hit by 300+ simultaneous origin requests — one from each POP that has the cache miss.

Origin shielding designates one POP (often called a "shield" or "regional cache") that sits between the edge POPs and origin. The flow becomes:

User → Edge POP (Tokyo) → Shield POP (US-East) → Origin

If the edge POP has a miss, it asks the shield. If the shield has the content, it serves to the edge POP. Only if the shield also has a miss does the request hit origin. Net effect: origin sees one fetch per piece of content, regardless of how many POPs need it.

AWS CloudFront automatically uses Regional Edge Caches as shields. Cloudflare offers Tiered Cache. Fastly has Shielding as an optional feature. For high-traffic sites, enabling shielding is one of the highest-impact CDN settings.

Cache fill: cold cache vs warm cache

When content is new, no POP has it yet. The first user request in each POP's region pays the full origin fetch cost. After that, the content is warm in that POP for the duration of its TTL.

This produces a characteristic latency pattern:

• Cold cache (first request per POP): User latency = network RTT to edge + origin fetch time + response transfer. Often 300-2000 ms.
• Warm cache (subsequent requests): User latency = network RTT to edge + response transfer. Typically 20-100 ms.

For workloads with very long-tail content (millions of unique URLs each requested rarely), cache hit rate stays low and warming the cache provides limited benefit. For workloads with concentrated traffic (most requests hit a small set of URLs), hit rates of 95%+ are achievable.

TLS termination at the edge

The CDN terminates TLS at the edge POP. The user's browser establishes an encrypted connection with the CDN, not with your origin. This is required for the CDN to be able to decrypt the request and determine what content is being requested.

Edge-to-origin can use a separate TLS connection (recommended) or HTTP (insecure but supported by some CDNs for legacy compatibility). Standard production configurations:

• Full (Strict): TLS user → edge, TLS edge → origin, CDN verifies origin certificate.
• Full: TLS user → edge, TLS edge → origin, but CDN does not verify origin certificate. Avoid in production.
• Flexible: TLS user → edge, HTTP edge → origin. Dangerous — the edge-to-origin hop is unencrypted. Origin sees HTTP, which can leak data to network observers.
• Strict (origin pull): Same as Full Strict but with mTLS — origin verifies the CDN's certificate too. Recommended for high-security environments.

TLS termination at the edge also means TLS handshake latency is paid to a nearby POP, not the origin. For users far from origin, this alone provides a measurable performance gain even before any caching.

Beyond caching: what modern CDNs actually do

CDNs in 2026 are not just caches. They have absorbed multiple adjacent functions:

• Compute at the edge. Cloudflare Workers, Lambda@Edge, Vercel Edge, etc. (see edge functions explained).
• DDoS mitigation. Volumetric and application-layer DDoS scrubbing.
• Web Application Firewall (WAF). Rule-based and ML-based attack blocking.
• Bot management. Detection and challenge of automated traffic.
• Image optimization. Resizing, format conversion (WebP, AVIF), quality tuning.
• Load balancing. Health-checked origin pools with failover.
• Authentication. JWT validation, OAuth, mTLS, Cloudflare Access.
• Rate limiting. Per-IP, per-API-key, per-path throttling.

For modern applications, "CDN" and "edge platform" have become roughly synonymous. The legacy "just cache static files" CDN persists, but the dominant products are full-stack edge platforms.

Why CDNs sometimes hurt performance

CDNs typically improve latency, but there are scenarios where they make things worse:

• Cold cache misses for a global audience hitting a single origin. The edge → origin hop adds latency vs. direct connection.
• Misconfigured cache keys. If every request has a unique cache key (e.g., session IDs in URL), cache hit rate is 0 and you pay the edge hop for nothing.
• Long-tail content. Massive content libraries where most URLs are requested once a month have permanent cold caches.
• API endpoints with personalized responses. Cannot be cached; using a CDN adds an extra hop with no caching benefit.
• WebSocket / streaming on poorly-configured CDNs. Buffering settings can break long-lived connections.

The decision to use a CDN should be informed by hit-rate measurement. Run a representative workload, measure cache hit rate, and confirm the proportion of cache hits times the latency savings exceeds the proportion of misses times the added hop cost.

Frequently Asked Questions

What is a CDN point of presence (POP)?

A POP is a physical location where the CDN runs edge servers — typically a colocation facility close to a major interconnection point. Cloudflare has 300+ POPs across 100+ countries; AWS CloudFront has 600+ edge locations across 100+ cities. Each POP serves users who are routed to it by the CDN's anycast or DNS-based routing. A POP holds a cache of recently-requested content; cache misses trigger a request back to the origin.

What is the difference between a cache hit, cache miss, and cache pass?

A cache hit means the edge has a fresh copy of the requested content and serves it directly without contacting origin — the fast path. A cache miss means the edge has no copy (or only a stale one) and fetches from origin before serving. A cache pass (sometimes called "BYPASS" or "UNCACHEABLE") means the request is configured not to be cached at all — every request goes to origin regardless. Hit rate is the primary CDN performance metric; 90%+ hit rate is the goal for static content.

What is origin shielding?

Origin shielding designates one or more "shield" POPs that always sit between the edge POPs and your origin server. When a non-shield POP has a cache miss, it asks the shield POP instead of the origin directly. The shield POP caches the response and serves it to other edge POPs that need it. This dramatically reduces the request load on your origin because only the shield POP's cache misses reach origin, not every edge POP's cache miss independently.

Why doesn't a CDN cache everything by default?

Because cached responses can serve stale data to users. The CDN follows the cache directives the origin sets via Cache-Control and similar headers. By default, most CDNs only cache responses that explicitly opt in (Cache-Control: public, max-age=...). Responses without explicit caching directives are passed through. This avoids accidentally caching dynamic content (logged-in pages, personalized feeds, API responses) that would break if served to other users.

How does a CDN handle HTTPS?

The CDN terminates TLS at the edge — it holds your domain's TLS certificate and presents it to users. The connection between the edge and your origin is a separate TLS connection. This is necessary because the edge cannot decrypt the user's request to determine what to cache without holding the TLS key. CDNs offer multiple modes: "Full" (TLS edge → origin), "Flexible" (HTTP origin, dangerous), and end-to-end with origin certificates verified by the CDN.