CDN Content Distribution & Caching 5 — Questions and Answers
Question 1: A CDN edge node receives a 'Vary: Accept-Encoding' header from origin. What does this instruct the CDN to do?
- Compress all responses before caching
- Cache separate versions of the resource based on the Accept-Encoding request header value (Correct answer)
- Ignore the encoding preference of the client
- Forward all requests to origin without caching
Correct answer: Cache separate versions of the resource based on the Accept-Encoding request header value
The Vary header tells the CDN to store distinct cached copies for each unique value of the specified request header (e.g., gzip vs. br vs. identity).
Question 2: What is 'cache stampede' (also called 'thundering herd') in CDN caching, and what is the primary mitigation?
- When too many CDN nodes overload origin simultaneously; mitigated by request coalescing (Correct answer)
- When cache entries corrupt during high traffic; mitigated by checksums
- When purge requests flood the CDN API; mitigated by rate limiting
- When browsers ignore cache headers; mitigated by stronger Cache-Control
Correct answer: When too many CDN nodes overload origin simultaneously; mitigated by request coalescing
Cache stampede occurs when a popular cached item expires and hundreds of simultaneous requests all miss and hit origin; request coalescing lets only one through.
Question 3: Which HTTP/2 feature can CDNs leverage to push content to browsers before they request it, reducing round trips?
- HTTP/2 multiplexing
- HTTP/2 Server Push (Correct answer)
- HTTP/2 header compression (HPACK)
- HTTP/2 stream prioritization
Correct answer: HTTP/2 Server Push
HTTP/2 Server Push allows CDN edge nodes to proactively send resources (CSS, JS) to the client alongside the initial HTML response.
Question 4: A CDN is configured with 'stale-while-revalidate=60'. What happens during that 60-second window?
- The CDN refuses all requests until revalidation completes
- The CDN serves the stale cached response immediately while asynchronously fetching a fresh copy in the background (Correct answer)
- The CDN waits 60 seconds before checking origin
- The CDN serves stale content only to non-authenticated users
Correct answer: The CDN serves the stale cached response immediately while asynchronously fetching a fresh copy in the background
stale-while-revalidate lets the CDN return stale content instantly (zero latency penalty) while triggering a background refresh within the window.
Question 5: Which content type is generally LEAST suitable for aggressive CDN caching with long TTLs?
- JavaScript bundles with hashed filenames
- Product listing pages with real-time inventory and pricing (Correct answer)
- Static images with versioned URLs
- Font files referenced by a fingerprinted CSS file
Correct answer: Product listing pages with real-time inventory and pricing
Product pages with live inventory and pricing change frequently and vary per user, making long TTLs inappropriate without smart invalidation.
Question 6: What is 'cache hierarchy collapse' and when is it desirable?
- Removing all mid-tier caches to reduce latency when origin can handle the load (Correct answer)
- Merging multiple CDN providers into one
- Deleting all cache entries simultaneously during a deployment
- Collapsing multiple TTL values into a single policy
Correct answer: Removing all mid-tier caches to reduce latency when origin can handle the load
Collapsing the cache hierarchy (removing parent/shield tiers) reduces latency hops but increases origin traffic, suitable only for low-traffic or highly dynamic origins.
Question 7: An e-commerce site uses a CDN and wants to cache product pages but show real-time cart counts. Which architecture achieves this correctly?
- Disable CDN caching for all product pages
- Cache the full product page HTML and use client-side JavaScript to fetch cart data from a separate non-cached API endpoint (Correct answer)
- Set TTL=1 second for all product pages
- Store cart data in CDN edge storage and sync every 5 minutes
Correct answer: Cache the full product page HTML and use client-side JavaScript to fetch cart data from a separate non-cached API endpoint
Separating cacheable page content from dynamic per-user data (fetched via API after page load) is the standard pattern for caching personalized pages.
A CDN edge node receives a 'Vary: Accept-Encoding' header from origin.
What does this instruct the CDN to do?