Tiered cache and Cache-Control

Your CDN is in front of the origin, but the origin alarm is still firing on every deploy. New users miss the cache, every edge POP fetches from origin simultaneously, and suddenly 200 edge servers generate 200 parallel origin requests for the same uncached URL. This is not a bug — it is a missing architecture layer: the origin shield.

The four-layer cache hierarchy

When a browser makes a request, four caches may answer before origin:

1. Browser memory cache (~sub-ms, in-tab lifetime)
2. Browser disk cache (~10 ms, persists across tabs)
3. CDN edge POP cache (~20–50 ms over the network from user)
4. CDN origin shield / regional cache (~50–100 ms)

Only if all four miss does the origin server answer (~100–300 ms depending on geography). Each layer obeys the same Cache-Control directives but applies them independently.

Cache-Control directives

The Cache-Control response header tells every caching layer what to do with the response:

Most important rule: without Cache-Control: public (or s-maxage) the CDN passes through — no caching happens. Origin response headers govern cacheability; the CDN cannot cache what the origin does not permit.

Origin shield architecture

Every CDN region may have dozens of edge POPs. Without a shield, a cache miss at all 200 POPs for a popular URL generates 200 simultaneous origin requests — a thundering herd.

Origin shield (called “Tiered Cache” at Cloudflare, “Origin Shield” at Fastly, same feature at CloudFront) is a regional intermediate cache between edge POPs and origin. All edge POPs in a region funnel their misses through one shield node. The shield maintains a larger cache; it typically absorbs 90%+ of misses without contacting origin.

Workflow for a cold URL:

1. 200 edge POPs all miss simultaneously.
2. All 200 forward to the regional shield.
3. Shield has one outstanding origin request; the other 199 queue.
4. Origin responds once; shield propagates to all 199 waiting edges.
5. Origin saw 1 request instead of 200.

Static-asset versioning: making invalidation unnecessary

The cleverest cache trick: include the content hash in the filename (e.g. app.f3a2b8c.js). Set max-age=31536000, immutable (1 year). When the file changes, the hash changes, the URL changes — the cache has no entry for the new URL and fetches fresh automatically. No purge needed. Tools that do this automatically: Webpack, Vite, esbuild, Astro.

Cache invalidation patterns (when you need them)

1. TTL expiry — wait for max-age to expire. Cheap, no API calls, but slow for urgent fixes.
2. Explicit purge — CDN API call: POST /purge {"url": "/api/products"}. Fast, but slow when purging thousands of URLs per deploy.
3. Cache tags — tag responses at origin (Cache-Tag: article-1001), purge by tag (POST /purge {"tag": "article-1001"}). Most flexible; requires CDN enterprise tier (Fastly, Cloudflare Enterprise).

Conditional requests and 304 Not Modified

After a browser’s local cache expires, it revalidates with If-None-Match: <etag>. If the response has not changed, the CDN (or origin) returns 304 Not Modified — empty body, saves bandwidth. CDNs handle ETags transparently for cacheable responses, forwarding to origin only when the ETag actually changed.