How do I cache API responses at the CDN without serving one user's data to another?

Use the Vary header to tell the CDN that the response depends on the Authorization header: Vary: Authorization. This creates separate cache entries per authorization token. For public endpoints that don't vary by user, set Cache-Control: public, s-maxage=300 without Vary: Authorization. For authenticated endpoints returning user-specific data, set Cache-Control: private, no-store to prevent CDN caching entirely. Never cache responses that contain user-specific data unless you include the user identifier in the cache key via Vary.

What is stale-while-revalidate and how does it help API availability?

stale-while-revalidate is a Cache-Control directive that allows the CDN to serve an expired (stale) cached response immediately while fetching a fresh copy from the origin in the background. For example, Cache-Control: s-maxage=60, stale-while-revalidate=30 means the CDN serves cached content for 60 seconds, then for the next 30 seconds serves stale content instantly while revalidating. Users never wait for the origin. This is powerful for API resilience — even if the origin is temporarily down, users get the last known good response.

How do I invalidate cached API responses across all CDN edge locations?

Three strategies in order of preference: (1) Versioned URLs — change the URL when content changes (/api/v2/products or /api/products?v=hash) so the CDN treats it as new content. (2) Surrogate keys / cache tags — tag responses with logical identifiers and purge by tag (supported by Fastly and Cloudflare). When product 42 changes, purge the 'product-42' tag to invalidate all responses containing that product. (3) Path-based purge via CDN API — invalidate specific URLs or wildcard patterns. Note that CloudFront purges take 1-5 minutes; Fastly purges are instant.

What is origin shield and when should I enable it?

Origin shield is an intermediate CDN caching layer between edge locations and your origin. Without it, a cache miss at each of 50 edge locations creates 50 separate requests to your origin. With origin shield, all edges route misses through a single shield location, collapsing 50 origin requests into 1. Enable it when: your origin is sensitive to traffic spikes, your cache hit ratio is moderate (40-80%), or you have global traffic hitting many edge locations. Choose a shield region geographically close to your origin for minimum added latency.

How do I debug why my CDN is not caching API responses?

Check five things: (1) Origin response headers — use curl -I against the origin directly and verify Cache-Control does not include no-store, private, or max-age=0. (2) Vary header — Vary: * or Vary: Cookie effectively disables caching. (3) HTTP method — only GET/HEAD are cached. (4) CDN-specific cache status header — check X-Cache (CloudFront), CF-Cache-Status (Cloudflare), or X-Cache-Hits (Fastly) to see if the CDN attempted to cache. CF-Cache-Status: DYNAMIC means Cloudflare saw no cacheable headers. (5) Query strings — ensure your CDN cache key policy includes or excludes query parameters as intended.

Using CDNs to Reduce Latency and Errors