CDN Edge Caching: Mermaid Flowchart Diagram

About Source

CDN edge caching is the mechanism by which a Content Delivery Network stores copies of assets — static files, API responses, or rendered pages — at geographically distributed Points of Presence (PoPs), serving cached content to users from the nearest location rather than every request hitting the origin server.

When a user requests a resource, DNS resolution (or anycast routing) directs the request to the nearest PoP. The edge node checks its cache store for the requested URL and cache key:

Cache hit: The object is present and has not exceeded its TTL. The edge returns the cached response immediately with minimal latency (often under 5ms). A CF-Cache-Status: HIT or X-Cache: HIT header confirms cache service.

Cache miss: The object is absent or expired. The edge forwards a request to origin (the application server, S3 bucket, or load balancer). The origin returns the response with Cache-Control headers (e.g., max-age=3600, public) that instruct the CDN on cacheability and TTL. The edge stores the response and returns it to the user, future requests hitting the cache.

Cache keys determine uniqueness. By default the full URL is the cache key. Vary headers, query parameters, cookies, and geographic location can extend the key, leading to more cache shards. Aggressive Vary headers (e.g., on User-Agent) effectively disable caching.

Cache invalidation lets operators purge stale content immediately — by URL, tag, or prefix — without waiting for TTL expiry. This is essential after deployments that change static asset content.

See Edge Computing Architecture for compute at the edge beyond caching, and Object Storage Lifecycle for managing cached assets in origin storage.

Frequently asked questions

CDN edge caching is the mechanism by which a Content Delivery Network stores copies of assets at geographically distributed Points of Presence (PoPs), serving cached responses to users from the nearest location. This reduces origin load and cuts response latency — often from hundreds of milliseconds to under 5ms for cache hits.

When a request arrives at a PoP, the edge node checks its local cache against the request's cache key (typically the URL). On a hit it returns the cached response immediately. On a miss it forwards the request to the origin, stores the response according to the returned `Cache-Control` headers, and serves the response — making all subsequent requests a hit until TTL expiry.

Use cache invalidation after any deployment that changes static asset content — new JavaScript bundles, updated images, or revised HTML — where serving stale content would cause user-visible bugs or inconsistencies. Waiting for TTL expiry is only acceptable for content where stale delivery causes no harm.

Setting overly broad `Vary` headers (e.g., varying on `User-Agent`) effectively disables caching by creating too many unique cache shards. Caching API responses that contain per-user data exposes private information to other users. Forgetting to configure cache invalidation on deploy leads to users receiving stale assets. Setting excessively short TTLs eliminates the caching benefit and increases origin load.

mermaid

flowchart TD
    User([User Request\nexample.com/image.png]) --> DNS[DNS / Anycast\nroutes to nearest PoP]
    DNS --> EdgePoP[CDN Edge PoP\nnearest location]
    EdgePoP --> CacheCheck{Cache Key\nMatch?}
    CacheCheck -->|HIT, TTL valid| CacheHit([Serve from Edge Cache\nX-Cache: HIT, under 5ms])
    CacheCheck -->|MISS or expired| OriginRequest[Forward to Origin\nLoad Balancer or S3]
    OriginRequest --> Origin[Origin Server\napplication or object storage]
    Origin --> CacheControl[Response with\nCache-Control headers]
    CacheControl --> StorEdge[Store at Edge\nrespect max-age, public]
    StorEdge --> ServeUser([Serve Response to User\nX-Cache: MISS])
    StorEdge --> FutureHit([Future Requests: HIT])
    EdgePoP --> VaryCheck{Vary Header\nor Cookie?}
    VaryCheck -->|Yes| ShardKey[Extend Cache Key\nmore cache shards]
    ShardKey --> CacheCheck
    Purge([Purge API Call\nby URL or tag]) --> InvalidateEdge[Invalidate Edge Cache\nall PoPs]
    InvalidateEdge --> ForceMiss([Force cache miss\nnext request fetches fresh])