Networking & Protocols
CDN and edge: multiple-choice review
Crux Multiple-choice synthesis across the CDN and edge unit — proximity routing, cache keys, tiered cache, stampede defence, edge compute, and production failure modes.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. None is a definition to recite — each one mirrors a routing, caching, or composition decision you make while the dashboard is on fire.
Goal
Confirm you can connect proximity routing, cache-key construction, tiered cache, stampede defence, and edge compute — the synthesis the individual lessons built toward.
Quiz
Completed
A site sets Cache-Control: public, max-age=3600 but CDN hit rate sits at 5% with thousands of distinct entries per URL. The most likely single cause?
Heads-up One hour is plenty for reuse on a busy URL; expiry would lower hit rate uniformly, not explode entry count into thousands per URL. Per-URL cardinality is the Vary footgun signature.
Heads-up A missing shield raises origin load on misses but does not multiply cache entries per URL. Thousands of entries per single URL points squarely at a high-cardinality Vary header.
Heads-up POP selection affects latency, not how many cache slots a URL has. The thousands-of-entries-per-URL symptom is cache-key fragmentation, i.e. Vary.
Quiz
Completed
A logged-in user loads /account and sees their name; an hour later a different anonymous user hits the same URL and sees the first user's name. CDN logs show cache hits for both. Root cause?
Heads-up Sharing a POP does not share response bodies — each request is keyed independently. The leak is that cookies are absent from the cache key and the response was not marked private.
Heads-up CDNs do not swap sessions. The personalised response was simply cached under a cookie-blind key and served to the next requester of that URL.
Heads-up SWR controls freshness over time for one keyed entry; it never crosses users. The defect is that a cookie-reading endpoint is cacheable at the shared CDN at all.
Quiz
Completed
A popular article's edge entry expires across 200 POPs in a region at the same instant; 1000 users request it that second, origin starts returning 503s, and those 503s get cached. Which two layers together would have prevented this?
Heads-up A longer max-age only delays the same synchronous expiry cliff, and Accept-Encoding does nothing for stampedes. The fix is collapsing concurrent misses (shield) and serving stale during revalidation (SWR).
Heads-up Routing chooses which POP answers; it does not change what happens when a cached entry expires. Stampede defence is a cache-tier concern, not a routing concern.
Heads-up private disables shared caching entirely, sending every request to origin — the opposite of stampede protection. SWR plus origin shield keep the herd off origin.
Quiz
Completed
A product page needs hour-stable chrome, a 10-minute-stale description, and a per-user price that must be real-time. no-store gives 300 ms p95; max-age=3600 shows stale prices. What is the senior move?
Heads-up no-store throws away the 90%+ of bytes that are perfectly cacheable just to keep one fragment fresh. Compose the page from per-TTL fragments instead of caching at one granularity.
Heads-up A 5 s TTL on the whole page still serves stale prices for up to 5 s and re-fetches everything constantly, hammering origin. Real-time price needs a fresh fragment, not a short whole-page TTL.
Heads-up Vary keys on request headers, not response data, and a per-price entry would be uncacheable noise. The price is fetched live by an edge worker, not encoded in the cache key.
Quiz
Completed
A latency-sensitive API on an intercontinental path is slow even though Anycast already sends users to the BGP-nearest POP. Why, and what is the targeted fix?
Heads-up More POPs do not fix BGP's latency blindness; the AS-path metric still ignores real RTT. You need a measurement-based routing layer over a private backbone, not more announcements.
Heads-up GeoDNS routes by the resolver's location (often the public-DNS provider's, not the user's) and is no more latency-aware than Anycast. The fix is active latency probing plus backbone transit.
Heads-up A longer TTL helps cacheable responses but does nothing for the dynamic, latency-sensitive calls that must reach a backend. The problem is transit path quality, addressed by smart routing.
Quiz
Completed
You ship a hotfix; origin is updated, yet 20 minutes later Europe serves the old version while Asia serves the new one. Why the split, and what is the durable fix?
Heads-up Software version does not determine cache freshness; independent per-edge TTL ages do. Without a deploy-triggered purge, each edge waits out its own remaining TTL.
Heads-up Origin is single and already updated; Anycast picks edges, not origins. The discrepancy is per-edge cache state, fixed by purging on deploy, not by routing.
Heads-up stale-if-error only triggers when origin returns 5xx; here origin is healthy. The split is ordinary per-edge TTL drift, resolved by an automated purge in the deploy pipeline.
Recap
The unit’s through-line is one delivery pipeline: routing (Anycast for scale and DDoS absorption, GeoDNS for control, smart routing to correct BGP’s latency blindness) puts the user on the right edge; the cache key (URL + method + Vary) decides what is reusable, and high-cardinality Vary or cookie-blind keys are the classic footguns; the tiered cache plus origin shield and stale-while-revalidate keep the herd off origin; edge workers and edge-side composition assemble per-TTL fragments for fast pages with fresh data; and operations close the loop with cache-tag purge, deploy-triggered invalidation, and per-region observability.