Origin TTL Conflict After a Cache-Hit Rate Drop
A retail site serves product pages through a CDN property. The origin team sets Cache-Control: max-age=300 on HTML responses. The property's caching rule for the HTML content type is configured with 'Honor origin TTL' enabled and a 'Force revalidation' behavior applied to the same path. After a marketing push, cache-hit rate for HTML falls from 92% to 58%, origin load triples, and the origin team reports a flood of conditional requests (If-None-Match) returning 304. The marketing team also wants price changes to appear within one minute. Traffic is 4,000 req/s at peak, HTML responses average 60 KB, and 70% of the audience is in one metro.
1. Diagnose why the hit rate collapsed and explain the interaction between the origin TTL, the revalidation behavior, and the observed 304 traffic.
Read the worked answer
The origin advertises 300s freshness, but the property forces revalidation on the same path. Forced revalidation means every request that would otherwise be a fresh cache hit is instead validated upstream. That is exactly the 304 flood: the edge still has the object but refuses to serve it without asking the origin. The hit rate drop from 92% to 58% is consistent with almost all HTML requests becoming revalidations rather than hits.
Key reasoning: TTL and revalidation are not additive safeguards; the stricter behavior wins. A 300s TTL is irrelevant if every request triggers a conditional GET. The 304s also don't reduce origin work much - the origin still parses the request, evaluates the ETag, and returns headers, so origin load triples even though bytes are small.
2. The marketing team wants price changes visible within 60 seconds. Recommend a configuration that restores hit rate while meeting that goal, and justify the trade-off.
Read the worked answer
Separate the two goals. Restore normal caching by removing blanket forced revalidation from the HTML path, then meet the 60s freshness requirement with a deliberate, bounded TTL.
Options, in order of preference:
- Set an edge TTL override of 30-60s on HTML and keep origin revalidation only as a fallback (honor origin TTL off, explicit override on). This bounds staleness to the TTL and eliminates per-request validation.
- Use a short TTL plus targeted purge: publish a purge (by tag or CP code) when prices change, so the 60s window is a ceiling, not the norm.
- Keep
stale-while-revalidate/stale-if-errorso the edge can serve slightly stale content while refreshing in the background, protecting origin during the refresh burst.
Trade-off: a 60s TTL means up to 60s of stale price for non-purged changes, but hit rate recovers and origin load drops. Blanket revalidation is the wrong tool - it guarantees freshness at the cost of cache effectiveness. With 4,000 req/s and 70% audience concentration, even a 30s TTL yields large hit-rate recovery in that metro.