Origin vs CDN edge: the distance every request pays
4 min read
Serve from your origin alone and every request crosses the full distance to one server; put a CDN edge in front and most requests stop at a cache a few miles from the user. The difference between origin-only and a CDN edge is not what the answer is but where it lives — one server far away, or many copies close by. Physical distance is the dominant term in request latency, so the shorter the trip, the faster the response, and a CDN's whole job is to make that trip short for every request after the first.
The origin-only path
Your server is in one place and your users are not. A reader in Singapore requests /logo.png; DNS resolves to your origin in Virginia; the request crosses the Pacific and so does the response. Every user pays that crossing, on every request — including the ten-thousandth request for a file that has not changed in a year. The distance is not incidental: Cloudflare states it plainly — the physical distance data must travel is the primary driver of latency, and origin-only pays it in full every time.
There is a second cost behind the first. All of that traffic terminates on one machine, so the origin carries the full load as well as the full distance — nothing is cached between the user and the server, so nothing is spared.
Edge caching vs origin: what actually changes
A CDN operates many points of presence worldwide and answers each request from the node closest to the user — Singapore or Tokyo, not Virginia. What that buys depends entirely on cache state:
- Cache miss — the first request for an object at a given edge. The edge fetches from the origin once, stores the copy, and returns it. This request still pays the full distance.
- Cache hit — every request after. The response only needs to travel as far as the nearest edge server. The ocean crossing does not happen.
So the edge does not remove the long trip; it amortises it — one long trip, then many short ones. That is the honest version of "a CDN makes your site faster," and it is why origin load collapses to the misses: the origin only hears about the traffic the edge could not already answer.
User
a reader in Singapore asks the nearest edge for /logo.png
Edge
cold cache — the edge has never held this object
Origin
the miss crosses to Virginia once, and the file comes back
Edge
the edge stores the copy and answers the reader
User
every later reader is answered from the edge — no ocean crossing
The edge does not delete the long trip; it pays it once on a miss, then serves the copy locally.
Where a CDN does nothing
The wins above are conditional, and two gaps catch everyone.
The first is the cold cache. A CDN does nothing for the first request at each PoP — that one still crosses the ocean, because the edge has to fetch what it does not yet hold. "Why is it still slow for me?" is usually someone hitting a PoP with an empty cache.
The second is bigger: a CDN does nothing for uncacheable responses. A personalised, logged-in API response has to be computed fresh, so it reaches the origin every time no matter how many edges sit in front of it. Putting a CDN before a dynamic app and expecting the static-asset win is the common disappointment.
Cache-control for CDN is the real control surface
A CDN caches what you tell it to, and the thing that tells it is your response headers. Most "the CDN isn't working" reports are a missing or wrong Cache-Control: mark a response no-store and every edge dutifully forwards it to the origin; give it a sensible max-age and the edge can hold it. Getting cache-control for CDN right is most of the work of actually using one. The number that shows whether it is working is your CDN cache hit ratio — the share of requests answered at the edge rather than forwarded to origin. A low ratio on assets that should be static almost always points back to a header.
When to put a CDN in front of your origin
Put a CDN in front when your traffic is geographically spread and a meaningful share of it is cacheable — static assets, images, scripts, public pages. That is where a nearby copy replaces a long round trip for nearly every request, and where origin load drops as a bonus. Expect little when the response is per-user and dynamic on every hit: there is no copy to reuse, so you are paying for edges that forward everything. The realistic middle is most apps — cache the static half at the edge, let the dynamic half reach the origin, and watch the split through your hit ratio.
Origin vs CDN Edge in a system design interview
An interviewer is usually not asking whether to use a CDN — the answer is yes — but whether you know why and where it stops helping. The crisp answer: a CDN cuts latency by serving from a cache near the user, because distance dominates latency; it does not remove the origin trip, it pays it once on a miss and reuses the copy on every hit. Expect the follow-up "so why not cache everything?" — name uncacheable, personalised responses and the cold-cache first request. If they push on measurement, reach for CDN cache hit ratio and how Cache-Control drives it. Framing it as edge caching vs origin — where the copy sits, not what it is — separates a rote "CDNs make things faster" from real reasoning about the failure modes.
