CDN Architecture for Headless Commerce — Multi-Layer Caching 2026
CDN architecture for headless commerce is layered — static assets, API reads, full-page edge cache, and tag-based purge — offloading 80-95% of traffic from origin.
CDN architecture for headless commerce is not “turn on a CDN” — it is a deliberate, layered caching strategy that offloads 80-95% of traffic from your origin. Good CDN architecture stacks four layers: static assets, API read responses, full-page edge cache, and a tag-based purge strategy that keeps it all fresh. Get the CDN architecture right and a headless store scales to traffic spikes on a modest origin; get it wrong and the origin buckles or customers see stale prices.
Search intent: informational with architecture-decision intent — developers and technical leads designing the caching layer for a headless storefront. We cover each of the four CDN architecture layers, the order to build them in, verification, and the purge strategy that prevents both staleness and origin spikes. This is the delivery layer beneath your rendering strategy and edge rendering choices.
CDN Architecture: Asset and API Caching Layers
The foundation layer of CDN architecture is static assets — JS, CSS, fonts and images served from the edge with immutable hashed filenames and long max-age (see the HTTP caching guide and Cache-Control reference). This is the highest-hit-rate, lowest-risk layer and the place to start. Layer two caches API reads: product and category responses from your GraphQL or REST API, cached at the edge with a short TTL (around 60 seconds) plus stale-while-revalidate so the edge serves instantly while refreshing in the background. The hard rule for this layer of CDN architecture: cache reads, never cache cart, account or checkout API calls — those must always hit fresh.
CDN Architecture: Full-Page Cache and Purge Strategy
Layer three of CDN architecture is full-page edge caching — SSR or ISR HTML cached at the edge for anonymous visitors, delivering sub-100ms TTFB for the bulk of catalogue traffic, with a strict bypass for logged-in users, cart and checkout cookies. Layer four is the purge strategy, and it is what separates robust CDN architecture from fragile setups: use tag-based purging so a price or stock change invalidates only the affected product and category pages via a webhook, never a full-cache purge. Full purges in production cause a thundering-herd of origin requests — the exact spike caching was meant to prevent. The Cloudflare caching documentation covers tag-based purge and cache-key configuration.
| Layer | Caches | Key rule |
|---|---|---|
| 1 — Static assets | JS, CSS, fonts, images | Immutable, long max-age |
| 2 — API reads | Product, category responses | Short TTL, never cart/account |
| 3 — Full page | SSR/ISR HTML, anonymous | Bypass logged-in + cart cookies |
| 4 — Purge | Invalidation strategy | Tag-based, never full purge |
CDN Architecture: Build Order and Verification
Build CDN architecture bottom-up: static assets first (immediate win, low risk), then API read caching, then full-page edge cache, then purge automation last once the layers below are proven. Verify each layer with cache-status headers (cf-cache-status, x-cache) — a product page should show HIT, a cart request should show BYPASS or DYNAMIC. Test the logged-in bypass obsessively: the catastrophic CDN architecture failure is serving one customer’s cart or account page to another from cache. Monitor origin offload percentage as your headline metric; a well-built four-layer CDN architecture keeps 80-95% of requests off origin. Our performance engineering team builds and audits this layered caching on every headless project.
What we have learned building CDN layers in production
Start with assets, end with purge. The temptation is to jump straight to full-page caching for the dramatic TTFB win. We build bottom-up because each layer’s correctness depends on the ones below, and full-page cache without a working purge strategy ships stale prices on day one.
Tag-based purge is the difference between calm and chaos. The single most damaging pattern we are called in to fix is a full-cache purge wired to every content save — every publish empties the entire edge cache and stampedes the origin. Tag-based purge invalidates only what changed.
Test the logged-in bypass like it is a security control — because it is. We add automated checks that a cart request never returns a cache HIT. Serving a cached personalised page to the wrong user is the worst failure mode in headless commerce, and it is entirely preventable with disciplined cache-key and bypass rules.
Frequently Asked Questions About CDN Architecture
What is CDN architecture for headless commerce?
CDN architecture for headless commerce is a layered caching strategy with four layers: static assets, API read responses, full-page edge cache for anonymous users, and a tag-based purge strategy. Built correctly it offloads 80-95% of traffic from origin and delivers sub-100ms TTFB for catalogue pages globally.
What should never be cached in a commerce CDN?
Cart, checkout, account and any authenticated API call must never be cached in CDN architecture — they are per-user and must always hit fresh. Full-page caching must bypass requests carrying logged-in or cart cookies. Caching personalised pages is the most dangerous CDN failure, as it can serve one customer’s data to another.
What is tag-based purge in CDN architecture?
Tag-based purge invalidates only the cached pages associated with a tag — for example, purging just the product and category pages affected by a price change, triggered by a webhook. It is the core of robust CDN architecture because it avoids full-cache purges, which stampede the origin with a thundering herd of uncached requests.
In what order should I build CDN caching layers?
Build CDN architecture bottom-up: static assets first (low risk, immediate win), then API read caching, then full-page edge cache, then purge automation last. Each layer’s correctness depends on those below it, and full-page caching without a working purge strategy ships stale content immediately.
How do I verify my CDN architecture is working?
Check cache-status headers like cf-cache-status or x-cache: a product page should show HIT, a cart request should show BYPASS or DYNAMIC. Test the logged-in bypass to confirm personalised pages never return a HIT, and monitor origin offload percentage — a good four-layer CDN architecture keeps 80-95% of requests off origin.
Does CDN architecture replace the need for fast origin?
No — CDN architecture offloads most traffic but cache misses, purges and uncacheable routes (cart, checkout) still hit origin. A slow origin shows through on every miss and after every purge. CDN caching and origin performance are complementary: cache aggressively, but keep the origin fast for the traffic that must reach it.
Designing CDN Architecture for a Headless Store?
Our team builds the four-layer caching stack — assets, API, full-page and tag-based purge — with verified bypass rules.
