Soft purge vs. hard purge: a London ticketing site survives a drop

Soft purge vs. hard purge: a London ticketing site survives a drop
A concert site hard-purged its event pages on every inventory change. During an on-sale, inventory updated every 2 seconds, so each purge flushed the cache and 40,000 waiting fans hit origin simultaneously.
Origin latency spiked to 2,100ms and the queue page itself started timing out.
They moved to soft purge: stale entries weren't deleted, just marked stale-while-revalidate. The edge served the slightly-old page instantly while one background fetch refreshed it.
Origin concurrent requests dropped from 40,000 to roughly 200. Page latency held at 90ms through the entire drop.
Hard purge when correctness is absolute — a leaked price, a legal takedown. Soft purge when a few seconds of staleness beats an origin meltdown.
The number that mattered: origin concurrency cut from 40,000 to 200.