A marketplace in the mould of eBay raises CDN cache TTL on product pages from 60 seconds to 24 hours and adds stale-while-revalidate. Origin requests fall by about 95%. What has it given up, and when does that bill arrive?

What is gained, quantified

Origin fleet sized for 5% of its previous read load, and a tail that is no longer the origin's problem: with stale-while-revalidate, an expired object is served immediately from the edge while it is refreshed in the background, so the p99 of a cache revalidation stops appearing in user latency. For a read-heavy catalogue this is often the difference between 40 origin instances and 4.

What is paid

The TTL has become the blast radius of every mistake. Three specific costs:

1. Correctness is now a purge problem. A price change, a withdrawn listing or a legal takedown is not live until the purge completes. Purge is a global distributed operation with its own latency - typically seconds, sometimes minutes - and providers rate-limit it. A publish workflow that issues 10,000 purges because an attribute changed on a category will be throttled, and the throttling is discovered during the incident.
2. A bad page is cached worldwide. At a 60-second TTL, a deploy that renders a broken template pollutes the cache for a minute. At 24 hours it pollutes it until purged, and the purge path is the one that just became load-bearing.
3. Cache-key completeness stops being a minor bug and becomes a disclosure risk. Any part of the response that varies by user - a currency, a region, a logged-in header - must be in the key or must not be in the cached document. At 60 seconds a key error leaks a page to a handful of users; at 24 hours it leaks it globally.

When the cost becomes visible

Not at rollout. At the first urgent correction, which is usually a mispriced item, and at the first bad deploy. Both arrive with an audience.

How to keep the option to reverse

• Purge on write, as part of the publish path, with the purge result checked rather than fire-and-forget. A purge that silently fails is a 24-hour-old price.
• Test the purge path on a schedule, the way a restore from backup is tested. An untested purge is not a control.
• Keep a short TTL for the subset that must be right now - price, stock, availability - and a long TTL for the body of the page. Fragment the document rather than the policy.
• Version in the URL for anything immutable (images, bundles), so correctness never depends on purge for those objects.

When this is the wrong trade

The decision rule: a long TTL is safe exactly when the purge path is reliable, fast and tested. If purge latency is unknown, your real correctness window is the TTL, so set the TTL to a value you could defend to a regulator. Where the simpler approach wins: a catalogue of a few thousand pages with low traffic, where a 60-second TTL already removes the load and no purge machinery is needed at all.