Caching makes content fast and cheap until it must change. Purge (invalidation) removes or marks content so the next request refills from origin. On adult platforms the hard cases are takedowns, rights changes, metadata edits, and launches — each with a different urgency and blast radius. Getting invalidation right is as important as getting caching right.
Purge methods
| Method | Targets | Speed | Best for |
|---|---|---|---|
| URL purge | Exact URLs | Fast, precise | A few assets, urgent takedowns |
| Tag / surrogate-key purge | Every object carrying a tag | Fast, broad | A title, an uploader, a whole catalogue group |
| Pattern purge | URL patterns (wildcards) | Broader, less precise | Bulk cleanup, path renames |
| Purge all | Entire resource | Slow, expensive | Emergency only; causes stampedes |
Choose the narrowest method that meets the need. Purge all on a busy resource is a self-inflicted stampede: every viewer’s next request misses at once and origin takes the full load. It is a last resort, not a routine tool.
Tag-based invalidation
Tagging is the workhorse for adult catalogues. When the edge fetches an object, the origin returns one or more tags (surrogate keys) identifying the content — a video ID, a channel, a category, a licence group. A later purge by tag invalidates every cached variant of that content across all URLs.
- Surrogate-key header limits matter. The header that carries tags has a bounded size and tag count per response; a title with hundreds of tags can be silently truncated, leaving part of the set un-purgeable. Keep tag sets small and hierarchical.
- Tags survive through the shield, so a tag purge reaches every edge holding a copy.
- Design a tagging convention before you need it. Retrofitting tags onto a large catalogue is painful; adding one more tag to new content is trivial.
Soft versus hard purge
A hard purge deletes the cached object. The next request is a miss and goes to origin — correct but expensive on hot content.
A soft purge marks the object stale and serves it while a single request revalidates origin in the background. Viewers keep getting fast responses, and origin sees one refill instead of a flood.
- Use soft purge for updates, metadata edits, and anything hot where a brief stale window is acceptable.
- Use hard purge for correctness-critical changes — rights removal, a takedown that must not serve — where even stale bytes are unacceptable.
- Prefer short TTLs plus soft invalidation over long TTLs plus frequent hard purges.
Tier and persistent-cache revalidation
Invalidation must reach every tier that holds a copy, not just the edge. A purge that clears the edge but not the shield or a persistent cache will see the object refill from the stale tier and come back. Ensure invalidation propagates edge → shield → persistent cache, and confirm the object is actually gone from each tier before declaring success. Verify with a cache-status probe rather than assuming.
Prefetch for launches
Cold caches hurt most at the moment of maximum demand. Prefetch warms content ahead of time: before a launch, a promotion, or a scheduled release, instruct the edge to fetch the objects so the first real viewer lands on a warm cache.
- Prefetch the hot set — the first segments of the titles you are promoting, the new landing page, the manifest — not the entire catalogue.
- Prefetch into the shield and the target regions, in the order viewers will request.
- Combine with origin capacity headroom for the actual spike; prefetch reduces misses, it does not eliminate the first fill.
- Re-run prefetch after any hard purge of the promoted set.
Where AdultInfra fits
AdultInfra designs invalidation that reaches every tier without causing stampedes, verifies soft and hard purge behaviour, and warms hot content before launches so the spike lands on a warm cache. Bring one hostname and the content lifecycle you need to control and talk to us.