Content Purge Path

Cheap media delivery depends on long cache lifetimes at every tier: browser, edge, shield, origin. Content moderation and legal removal require the opposite — that an object stops being served everywhere, quickly.

Without a dedicated mechanism the choices are short TTLs everywhere, which is expensive, or content remaining available after removal, which is unacceptable. A purge path separate from ordinary invalidation resolves both.

Why it matters

The removal requirement is frequently legal, with a deadline and a consequence attached. Discovering during a takedown that content is cached at a hundred edge locations with a seven-day TTL and no purge capability is a compliance failure, not an engineering inconvenience.

Implementation patterns

• A purge API reaching every tier, including intermediate shields, with confirmation rather than best-effort dispatch.
• Measured propagation time, so the organisation knows its actual removal SLA rather than assuming one.
• Purge by tag or surrogate key, not only by URL, so removing an item removes all its renditions, thumbnails and derived variants — which is where partial takedowns come from.
• Fail-closed at the origin. Even if a cache tier misses the purge, the origin must refuse to serve the object, so a stale edge copy expires rather than being refreshed. This is the backstop that makes the system defensible.
• An audit record of what was purged, when, on whose authority, and the confirmed propagation — because a takedown will be asked about.
• Separate from ordinary invalidation, with its own priority and its own alerting, since a purge failure is a different severity from a stale-content failure.

Industry example

Any platform serving user-generated content at scale — ShareChat, Pratilipi, video platforms — carries this requirement, and it interacts directly with the cost architecture. The cheapest delivery configuration is the one that makes removal hardest, so the purge path is what buys back the ability to use long TTLs.

The same mechanism serves security purposes: revoking a leaked object, removing content published in error, and withdrawing a signed asset.

Failure scenarios

• Purge by URL only, leaving renditions and thumbnails available.
• Best-effort purge with no confirmation, so a failed tier is undetected.
• No origin fail-closed, so a missed edge simply refreshes the content on expiry.
• Client-side caches ignored, which cannot be purged at all — the reason some content requires short browser TTLs even when edge TTLs are long.
• No measured propagation time, so the compliance answer is a guess.

Trade-offs

A purge path is infrastructure that is rarely exercised and must work perfectly when it is, which is the hardest combination to maintain. The mitigation is to use it routinely for non-urgent cases so it is exercised continuously rather than only in emergencies.

Short browser TTLs on user content are the residual cost — client caches cannot be purged, so anything that must be removable within minutes cannot be cached on the device for hours. That is a real delivery cost accepted for a real legal requirement, and it should be a deliberate per-content-class decision rather than a global setting.

Interview question

"You receive a legal order to remove a video within one hour. Walk me through every place a copy exists and tell me which ones you can actually guarantee."