Edge Server

Edge servers are the workhorses of any CDN. These are the servers deployed at Points of Presence (PoPs) around the world, sitting as close to end users as possible. Their job is straightforward: serve cached content fast and handle all the heavy lifting that would otherwise hammer your origin. That includes TLS termination, HTTP/2 and HTTP/3 negotiation, Brotli/gzip compression, and of course serving cached responses.

When a user makes a request, DNS resolution or anycast routing sends them to the nearest edge server. If that edge has the content cached (a cache hit), it responds directly, often in single-digit milliseconds. If it does not have the content (a cache miss), it needs to fetch it from upstream. In most CDN architectures, this means the request travels through a hierarchy: user to edge (L1 cache) to origin shield (L2 cache) to your actual origin server. Each layer reduces load on the one behind it.

You can usually tell which edge server handled your request by looking at response headers. Most CDNs include headers that identify the PoP location, cache status, and server ID. This is incredibly useful for debugging.

curl -sI https://example.com/image.jpg | grep -iE "(x-cache|x-served-by|cf-ray|x-amz-cf-pop|server-timing)"
# Fastly example:
# x-served-by: cache-ams21041-AMS
# x-cache: HIT
# Cloudflare example:
# cf-ray: 7a1b2c3d4e5f-AMS
# CloudFront example:
# x-amz-cf-pop: AMS1-C1

The "AMS" in those headers tells you the request was served from an Amsterdam edge server. If you see a cache miss, the edge had to fill from upstream, which adds latency. Monitoring hit ratios per edge gives you a clear picture of how well your caching strategy is working.