An edge platform can invalidate cached content either by short TTLs or by explicit purge on publish. Compare the two, and explain when a hybrid is required.

Short TTL

How it works. Objects expire on a timer; the next request revalidates against origin.

Gains. Simple, stateless and self-healing. No coordination, nothing to fail. Freshness is bounded by the TTL regardless of what breaks elsewhere. Content is never stale for longer than the TTL, which is a guarantee that survives every failure mode.

Costs. Freshness and origin load are the same dial. Every reduction in staleness multiplies origin traffic, and you pay that cost continuously for content that mostly did not change. At a large catalogue with a five-second TTL, origin sees the entire catalogue's request volume rather than its change volume.

Explicit purge

How it works. Publishing sends an invalidation for the affected objects; edges drop them and fetch fresh copies on next request.

Gains. Long TTLs and high hit ratios and near-immediate propagation. Origin load becomes proportional to the change rate rather than the request rate — a fundamentally better scaling relationship. Enables surrogate keys, where one purge invalidates every object tagged with a changed entity.

Costs. It is a distributed system with real failure modes. A purge can be lost, arrive out of order, or partially propagate, leaving some regions stale with no expiry to save them. It requires knowing which objects a change affects, which is genuinely hard when pages compose many entities. And it introduces a coupling: the publishing system must reach the CDN, so a CDN control-plane problem becomes a content-freshness problem.

Why the hybrid is required

Purge alone has no floor. If an invalidation is lost, the object is stale until something else evicts it — potentially forever with a long TTL. That is an unbounded correctness failure caused by a transient network event, and it is the reason purge-only designs eventually produce a mystifying incident where one region serves week-old content.

So: long TTL as the correctness backstop, purge as the freshness mechanism. The TTL bounds the damage of a lost purge; the purge means the TTL is almost never reached.

Add stale-while-revalidate and the design is essentially complete: the edge serves the stale copy instantly while refreshing behind the request, so revalidation never appears in user latency, and a temporarily unreachable origin degrades to slightly-stale rather than to errors.

The mechanism that makes purge tractable at scale

Surrogate keys. Tag each cached response with the entities it contains — an article id, a product id, a pricing group. Publishing purges by tag rather than by URL. This solves the hardest part of explicit invalidation, which is not delivering the purge but knowing what to purge, and it is what makes composed pages cacheable at all.

The rule

Use TTL where change is unpredictable or the content is unimportant. Use purge where publication is a known event and freshness matters. Use both where freshness matters and being wrong is unacceptable — which is most content that anyone cares about.