Edge and origin servers

The previous article named the pipeline a request follows inside a point of presence and flagged the origin fetch as its own separate concern. That fetch — an edge node reaching back to the origin server it fronts — is where a badly designed CDN setup does the most damage, because a mistake there doesn't just slow down one cache node. It can turn a launch-day traffic spike into an origin outage the CDN was specifically supposed to prevent.

What "origin" actually means

The origin server is wherever the real, authoritative copy of the content lives — the application server, the object storage bucket, the database-backed API — before any CDN gets involved. Every edge node's cache is, by definition, a copy of something the origin produced; when a cache entry is missing or expired, the edge node has exactly one place to go get a fresh answer, and that place is the origin.

This relationship inherits everything this course has already covered about reverse proxies: a CDN edge node is functionally a reverse proxy sitting in front of the origin, terminating the client's connection and opening its own separate connection onward. TLS termination usually happens twice in this path — once between the visitor and the edge node, and, depending on configuration, again between the edge node and the origin — which is a detail worth checking rather than assuming, since an origin that only accepts HTTPS needs the edge node configured to re-encrypt on the second leg rather than forward plain HTTP.

Visitor ──HTTPS──▶ Edge node (PoP) ──HTTPS or HTTP, per config──▶ Origin server

Every PoP is a separate visitor to your origin

The most consequential thing about the edge-to-origin relationship is one this course's previous article already set up: each PoP caches independently, so each one treats a cache miss as its own private problem to solve by asking the origin. From the origin's perspective, a CDN with 200 PoPs worldwide doesn't look like "one CDN forwarding some traffic" — it looks like up to 200 separate clients, each capable of opening its own connections and issuing its own requests, all fronting for the same set of real visitors.

That distinction matters directly for capacity planning. An origin sized to handle the CDN's overall expected cache-hit-adjusted traffic can still be blindsided by a cold cache event: a new piece of content goes live, gets popular quickly, and every PoP that hasn't yet served it independently sends its own first request to origin at roughly the same time. A CDN with many geographically fine-grained PoPs, as the earlier article on CDN internals touched on, actually makes this specific failure mode worse, not better — more PoPs means more independent "first requesters" hitting the origin during exactly the moment a spike begins, even though the CDN's steady-state cache hit ratio, once every PoP has warmed up, ends up excellent.

Origin shielding: giving the origin exactly one caller

The fix CDN providers converged on is called origin shielding (or just "shielding," the term this course uses going forward). Instead of every PoP being free to contact the origin directly on a miss, the provider designates one specific PoP — usually chosen for proximity to the origin itself — as the shield. Every other PoP, on a cache miss, doesn't go to the origin at all; it asks the shield PoP instead, and only the shield PoP is allowed to actually contact the origin.

Without shielding:
  PoP (Tokyo)   ──miss──▶ Origin
  PoP (Sydney)  ──miss──▶ Origin
  PoP (Mumbai)  ──miss──▶ Origin
  (three separate origin requests for the same cold object)

With shielding (shield PoP: Singapore):
  PoP (Tokyo)   ──miss──▶ Shield PoP (Singapore) ──miss──▶ Origin
  PoP (Sydney)  ──miss──▶ Shield PoP (Singapore) ──(already cached from Tokyo's request)
  PoP (Mumbai)  ──miss──▶ Shield PoP (Singapore) ──(already cached from Tokyo's request)
  (one origin request total; the other two are served from the shield's own cache)

The shield PoP becomes, in effect, a second caching layer sitting between the edge and the origin. The very first PoP to miss on a given object still has to wait for the shield to fetch it from origin — shielding doesn't eliminate the first cache miss, it eliminates the redundant ones that would otherwise come from every other PoP independently discovering the same gap. For an object popular enough to be requested from many regions in a short window, that's the difference between one origin request and dozens.

Shielding costs something too: every miss now takes one extra network hop (edge to shield, shield to origin, instead of edge straight to origin), so a shielded setup trades a small amount of worst-case latency on a true cache miss for a large reduction in overall origin load. For content that's genuinely popular across many regions, that trade is close to free; for content that's only ever requested from one geographic area anyway, shielding adds a hop with little benefit, since there was never redundant cross-PoP demand to eliminate in the first place.

Origin pull versus origin push

There's a second, independent design choice underneath all of this: whether the origin waits passively to be asked (origin pull, what every example so far in this course has assumed) or actively sends content out to edge nodes ahead of any request (origin push).

Origin pull is the default for most CDN use cases and everything described above: content only ever reaches an edge node because a client's request triggered a cache miss there. It requires zero coordination from whoever runs the origin beyond setting correct Cache-Control headers — the CDN does all the work of deciding what to fetch and when.

Origin push inverts that: the origin (or an operator, through the CDN's API or dashboard) proactively uploads content to edge locations before any visitor has asked for it. This shows up in practice for large, predictable files — a game patch, a software release, a video file being prepared for a scheduled launch — where the team already knows exactly which object will be in high demand at a specific moment and would rather pay the cost of distributing it in advance than let the first wave of real visitors trigger it as a cold-cache event.

Most CDN deployments use pull as the default and push, where the provider supports it, only for specific content the team can predict in advance. Neither replaces Cache-Control — push still respects the same caching-lifetime headers once content is sitting at the edge, and a pushed object with no-store set would be as uncacheable as a pulled one.

Practical scenario: an origin overwhelmed despite a CDN in front of it

A media company schedules a video release, expects heavy simultaneous global traffic the instant it goes live, and enables their CDN beforehand assuming that alone is sufficient protection. At launch, the origin's monitoring shows a sharp spike in connections and elevated response times for several minutes before settling down.

curl -s https://origin-internal.example.com/metrics | grep -i "active_connections\|requests_total"

active_connections 812
requests_total 4023

Investigating the CDN provider's own origin-request logs (distinct from the edge-facing access logs, which would only show a healthy near-100% cache hit ratio) shows dozens of near-simultaneous origin requests for the exact same video file, each one tagged with a different originating PoP — precisely the cold-cache-event pattern described above, not a CDN misconfiguration or a caching-header mistake. The team's Cache-Control was correct throughout; the object simply hadn't been cached anywhere yet, and dozens of PoPs discovered that gap within the same few seconds of the launch.

The fix for a genuinely predictable spike like a scheduled release is to avoid relying on pull-on-demand caching to absorb the very first wave of traffic at all: either enable shielding beforehand so the spike converges on one shield PoP instead of hitting origin from dozens of locations independently, or pre-warm the CDN by requesting the content through every relevant PoP (or using the provider's push/pre-fetch mechanism, where offered) before the scheduled launch time, so the cache is already populated everywhere before real traffic arrives. Both approaches solve the same underlying problem — a foreseeable cold-cache event doesn't have to be discovered by real user traffic — by different means.

Practice exercises

1. A CDN provider enables shielding, and a team observes that the very first request for a brand-new object still takes noticeably longer than a warm cache hit, even with shielding on. Is this expected behavior, or a sign shielding isn't working? Justify your answer using the shielding diagram above.
2. Contrast, in one or two sentences each, why a company distributing a scheduled 20 GB game patch to millions of simultaneous downloaders might prefer origin push, while a general news website with unpredictable, long-tail article traffic is better served by origin pull.
3. An origin server requires HTTPS for every incoming connection and rejects plain HTTP outright. Explain what has to be configured correctly on the edge-to-origin leg of the path shown in the first diagram above for this origin to work behind a CDN at all.

Shielding and pre-warming both assume the cache eventually needs refreshing — content changes, and a stale copy has to be replaced with a current one. How a CDN decides an entry has gone stale, and how an operator forces that replacement immediately when waiting for a TTL to expire isn't an option, is the last piece of the edge-caching picture this sub-module covers.

Sources

• Fastly, Shielding
• web.dev, Content delivery networks (CDNs)