Purging is the half of caching nobody designs: TTLs get a table, purges get a panic button. This guide treats invalidation as a system — the three purge types and their real costs, how to design surrogate-key tagging, the event wiring that makes freshness automatic, and the protections that keep a big purge from stampeding your origin.
The three purge types and their costs
Platforms offer up to three invalidation granularities, and each has a distinct cost profile. Single-URL purge is universal, fast on modern platforms, and per-purge cheap or free — but it requires knowing every affected URL, which is exactly what you don't know when one product appears on twenty pages. Wildcard/prefix purge trades precision for coverage; note that some platforms price or throttle it differently, and that its blast radius makes it the main stampede source. Tag (surrogate-key) purge — attach labels to responses at the origin, purge by label later — is the professional's tool: one call invalidates precisely the pages containing product 4711, however many and wherever they are. Support and semantics vary by platform and plan (part of what the rules engines comparison maps); if your platform offers tags and you aren't using them, that gap is this guide's main assignment.
Design your tags before you need them
Tagging works when the vocabulary is designed, not accreted. Tag each response with the entities it renders — product-4711, category-shoes, author-jm, plus coarse classes like html or listing — emitted by the origin in the surrogate-key header at render time, when the template knows exactly which entities it touched. Three design rules keep the vocabulary useful: tags name entities and classes, never moments (no deploy-tuesday); cardinality stays bounded (tag with the product ID, not the user ID — per-user tags mean per-user cache entries were already a mistake); and the vocabulary is documented in the repo next to the TTL table, because a tag scheme two engineers remember is a purge scheme that fails in year two. Header size limits (a few KB of tags per response, varying by platform) are the practical ceiling on how fine you can slice; entity + class level fits comfortably.
Wire events, not humans
Freshness becomes automatic when purges ride your write paths. The wiring: every mutation that changes rendered content — publish, price change, stock-out, profile edit — emits the affected tags to a small purge dispatcher, which batches (dozens of tags coalesce into one API call), deduplicates (the same tag purged once per burst, not per event), retries with backoff (purge APIs have outages too; a lost purge is a stale page with no alarm), and logs (section five). CMS and commerce platforms usually have hook points or maintained plugins for the popular CDNs; custom stacks put the dispatcher next to the outbox/webhook layer they already have. The standard this wiring should reach: no human runs a routine purge, ever — manual purging is for incidents, and if your team purges by hand weekly, that is a missing event hook wearing a process costume.
Big purges without the stampede
A purge is a promise of misses, and a large one — wildcard on a hot prefix, a tag spanning thousands of pages, purge-all — converts your traffic into simultaneous origin fetches. Three protections keep big purges survivable. Request collapsing (concurrent misses for one object coalesced into one origin fetch) is your main shield — confirm it is on and works at your scale before you need it. Origin shield adds a second collapse layer across the whole edge, per the shield comparison — the difference between one fetch per object per POP and one per object. Soft purge, where supported, marks entries stale instead of deleting them, letting the stale-while-revalidate machinery from the serve-stale guide refill gently in the background — prefer it over hard purge for everything except legal-removal cases where the bytes must not serve again. And schedule genuinely optional big purges off-peak; the same purge at 4 a.m. costs a fraction of its 8 p.m. self.
The purge log and the drill
Two operational habits complete the system. Keep the purge log queryable — who/what/why for every purge, from the dispatcher and any manual action — because purge is state-destruction and debugging "why did hit ratio crater at 14:02" or "why is this page still stale" starts there; alert on anomalies (purge-all outside a change window, purge volume spiking) the way you would on deletions anywhere else. And drill the incident path quarterly: the wrong-content-published scenario, timed from detection to global removal, including the legal-removal variant where soft purge is insufficient. Purge latency itself is worth measuring on your own estate — publish a canary object, purge, and time until edges worldwide stop serving it — because "instant" claims vary in practice, and your incident runbook should contain your number, not the brochure's.