Why this matters

If you run a streaming product on a CDN, somebody on the team will, sooner or later, propose "let's just purge the cache" as a fix for a problem. They will not be wrong about the symptom — old content being served. They will almost always be wrong about the tool. Indiscriminate purging is slow on most CDNs, expensive past a small free tier, and silently destructive to the cache hit ratio that pays your bills. This article is for the engineer who has been handed the purge button, the platform lead who wants to know when it is actually the right answer, and the product owner who needs a one-page checklist before the next "urgent takedown" lands in the team's lap.

What "cache invalidation" actually means

A CDN holds copies of your files at the edge — close to the viewer — so it can serve a request without going back to your origin server. Cache invalidation is the act of telling the CDN: forget the copy of this file you have, and the next time anyone asks for it, fetch a fresh one from origin. The word purge is used as a synonym by most CDNs (Cloudflare, Fastly, Akamai, Google Cloud CDN), and invalidation is the term Amazon CloudFront prefers; the operation is the same.

Three details inside that simple definition trip teams up.

First, invalidation is not instant. CloudFront documents 5–25 seconds for its new cache-tag invalidations (P95) and 10–15 minutes for traditional path invalidations to propagate across every edge in the network. Fastly is famously fast at this — its purge-all completes globally in roughly 150 milliseconds — but for live segments that already left the cache and are inside a player's buffer, even 150 ms is too late.

Second, invalidation costs money once you do it at any scale. CloudFront's first 1,000 invalidation paths per month are free; everything above that is $0.005 per path. A wildcard path (/season-3/*) counts as one path even if it matches a hundred thousand objects, which is why "purge a prefix" is almost always cheaper than "purge each segment". Akamai and Cloudflare both publish steep enterprise quotas above which throttling kicks in.

Third, an invalidated object is not deleted at origin. Invalidation only clears the CDN's cached copy. If the underlying file at origin is still the bad version, the very next request after the invalidation pulls the bad version back into cache, and you have spent an invalidation for nothing. The order is: fix the origin first, then invalidate.

Three stacked panels showing one CDN edge cache in three states. Panel A, a cache hit: a Viewer box marked 'a request' points to an Edge cache box marked HIT, and the notes read last mile about 30 ms, origin egress 0 bytes, cost zero, and a tuned CDN sits here 99% of the time. Panel B, an operator invalidation: an Operator box marked 'purge API' points to an Edge cache box marked 'evicted', and the notes give propagation of 150 ms on Fastly and 10 to 15 minutes on a CloudFront path, 1,000 CloudFront paths per month free and $0.005 for each one after that with a wildcard counting as one path, and warn that the bad file is still there at origin. Panel C, the next request: an Edge cache box marked MISS points to an Origin box that serves bytes, and the notes read the same bad bytes land back in cache, you spent an invalidation for nothing, fix origin first then invalidate, and it clears the cached copy, not the file. Two closing lines say invalidation deletes nothing at origin and that the origin is fixed first. Figure 1. What invalidation actually does — and what it does not.

Why "purge the URL" is the wrong move in a streaming pipeline

Static-site teams reach for purge as their default tool because their content model rewards it. A blog post changes; you purge the URL; the world sees the new copy in seconds. That habit transfers badly to streaming because a stream is not one URL — it is a tree of URLs whose shape changes second by second.

A typical HLS live stream is a master playlist, four to six media playlists (one per rung of the bitrate ladder), one initialization segment per rendition, an encryption-key URI, and a tail of media segments that the packager adds and removes from the playlist every few seconds. A single concurrent viewer fetches around 30 distinct URLs per minute on a 4-second segment cadence. A ten-thousand-viewer event has hundreds of thousands of objects in cache at any moment.

If your reflex is "the stream looks wrong, purge it", you face a few uncomfortable facts. You cannot purge the segments that are already inside the players' buffers — they have left the CDN entirely and are inside the viewer's device. You probably cannot purge faster than the packager produces new segments — for a 2-second segment, by the time a global purge has propagated, three new segments exist that you did not purge. And the act of mass-purging the live origin is one of the few operations that can actually break the stream — every player simultaneously revalidating to origin will collapse your origin connection pool.

For static VOD assets the math is gentler but the reflex still misfires. The right question is almost never "how do I purge?". It is "why am I in the position of needing to purge?". In a healthy streaming pipeline, that question has a small number of answers, and four other tools resolve each of them at lower cost.

The four tools that replace invalidation in streaming

Treat invalidation as the fourth choice on this list, not the first. The first three handle 95% of the workload.

Tool 1 — short Cache-Control on the things that change

Manifests change constantly during live streams. They should be cached at the edge for as little time as practically possible, so a player that asks for a fresh playlist actually gets one. The widely cited rule of thumb is half the target segment duration: a stream with a six-second target duration sets the playlist's max-age to three seconds; a stream with two-second segments uses one second. Apple's HLS Authoring Specification phrases the same idea by binding the playlist's freshness to the next-segment availability time.

For media segments — which never change once they exist — go the other way: Cache-Control: public, max-age=31536000, immutable. The immutable directive (defined in RFC 8246) tells browsers and CDNs that they can skip even the cheap revalidation round trip. The combination of "1-second manifest" and "1-year immutable segment" is the foundation of every well-tuned streaming CDN configuration.

Tool 2 — versioned filenames

If a segment really needs to change — usually because you re-encoded it, fixed an ad insertion, or repaired a stutter — change its name. Object season-3/episode-7/v1/segment-00042.m4s becomes season-3/episode-7/v2/segment-00042.m4s. The manifest now points at the v2 path; the CDN sees an URL it has never cached; the origin serves the fresh bytes; the v1 URL ages out of cache on its own.

This is the pattern that lets you set max-age=31536000 on segments without fear. You never have to invalidate a segment if its name changes any time its bytes change. CloudFront's own documentation calls this out as the first-class approach. Bitmovin, Mux, and AWS Elemental MediaPackage all default to versioned segment paths for exactly this reason.

The math: a CDN serving versioned segments at a 99% cache hit ratio costs roughly 1% of the same workload without versioning, because the rare misses happen only when a viewer is the first one to ask for a brand-new URL. A team that purges every deploy pays the cost difference every single time.

Tool 3 — segment-timeline rewrites

For live streams, the manifest itself is the invalidation primitive. The packager removes a segment from the media playlist's window (HLS) or from the SegmentTimeline element (DASH) and players stop asking for it on their next refresh. The DASH-IF Implementation Guidelines describe this explicitly: "the last period may change from unlimited duration to fixed duration … or one or more periods may be removed entirely from the end of the MPD timeline." HLS uses EXT-X-MEDIA-SEQUENCE and the sliding window of EXTINF entries to the same effect.

This is invisible to the viewer. The bad content rolls off the playlist; players reload the playlist within the target-duration window; the segment is forgotten by every new viewer within seconds. The CDN's stale copy of the segment file is irrelevant because nobody asks for it.

The pattern works for live for the same reason it does not work for VOD: a live manifest is dynamic; a VOD manifest is not. For VOD you fall back to tool 2 (versioning) or tool 4 (real invalidation).

Tool 4 — actual cache invalidation, but only when the other three can't help

When you have used tools 1–3 and the bad content is still being served to viewers right now, invalidation is the correct answer. The right-sized examples are surprisingly narrow. We will name them below.

A decision tree headed 'Why does the cached content need to change?' with four rows. Row A: the manifest changes every few seconds on a live HLS playlist, DASH MPD or master playlist, which leads to Tool 1, short Cache-Control, with max-age about half the target segment duration and no purge required. Row B: segment bytes must change after a re-encode, an audio fix or a new ladder rung, which leads to Tool 2, versioned filenames, where v1/seg-00042.m4s becomes v2/seg-00042.m4s and the manifest follows, with no purge required. Row C: a live segment leaves the playlist when the stream ends or the DVR window slides, which leads to Tool 3, segment-timeline rolloff, where the packager drops it and nobody asks for it, with no purge required. Row D: bad content is live now and A to C cannot help, as in a DRM key revoke, a takedown, one bad asset or a pullback, which leads to Tool 4, invalidation at the CDN by path, prefix or cache tag with origin fixed first, marked slow, paid and rate-limited, a last resort. A legend marks the first three green as designed in, free and instant, and the fourth orange as operator action. Figure 2. The decision tree every team should have on the wall before they touch the purge button.

When invalidation is the right tool

Four scenarios, drawn from real production streaming work.

A DRM key rotation, mid-flight

Common Encryption (CENC, ISO/IEC 23001-7) and the EME license model both support key rotation for continuous live content: the encryption key changes on a defined cadence, segments after the rotation point are encrypted with a new key, and players acquire the new license before the rotation time. If the rotation fires earlier than planned — typically because a subscriber's entitlement was revoked — you may need to invalidate the cached key-URI response so the next request triggers a fresh license fetch. The segments themselves do not need invalidation; the key does.

The mechanism is small and surgical: purge the path under the EXT-X-KEY URI (HLS) or the ContentProtection URL (DASH). Nothing else. Done within seconds, it cuts off the revoked viewer at the next key-fetch interval without disturbing the stream for anyone else.

A DMCA, GDPR, or right-to-be-forgotten takedown

If a third party files a Digital Millennium Copyright Act notice on a piece of VOD, the safe-harbour requirement is to remove it "expeditiously" — typically within 24 hours. The same urgency applies to General Data Protection Regulation erasure requests and to bespoke contractual takedowns (a sports league pulling highlights for a regional blackout).

The procedure: pull the asset's origin files first, then invalidate the wildcard prefix at the CDN, then leave a 410 Gone or 451 Unavailable response at origin in case anyone retrieves a cached URL during the propagation window. Versioning does not solve this — the bad version was the only version, and "forgetting v1" is the entire requirement.

A deployed bug in a single piece of content

You shipped a new transcode of a 90-minute movie. A QA engineer notices the audio is two frames out of sync, but only on the 720p rendition. Re-encoding takes an hour. You cannot wait an hour with the broken file in front of 50,000 viewers.

The pragmatic move is: re-encode under a new versioned path (tool 2), update the manifest to point at the new path, and invalidate only the manifest so the CDN's cached copy of the master playlist refreshes immediately. The broken segments age out of cache on their own. You spend one invalidation, not 800.

A live stream that went genuinely wrong

A presenter said something the legal team cannot keep on the public stream. You need to cut the stream window short and remove the recorded VOD before it is published. Live: stop ingesting; let the manifest's segment timeline roll off in seconds. VOD: pull the origin assets first, then invalidate the wildcard at the CDN, then publish a clean replacement under a new version.

This is the canonical scenario where every other tool is too slow — the playlist roll-off handles the live part, the wildcard invalidation handles the VOD part, and versioning handles the replacement.

How the major CDNs implement invalidation in 2026

The same operation has six vocabularies. The table below is the one most teams wish they had on day one.

CDNOperation namePath scopeTag / surrogate-key scopePropagation timePricing notes
Amazon CloudFrontInvalidationPath + wildcard (/path/*)Cache Tag (April 2026) via response header10–15 min (path); < 5 s P95 (tag)First 1,000 paths/month free; $0.005 each above
Akamai (CDN / Adaptive Media Delivery)Fast PurgeURL, CP code, ARLEdge-Cache-Tag headerRoughly 5 secondsIncluded in commit; rate-limited
CloudflarePurgeURL, prefix, hostname, everythingCache-Tag header (Enterprise)< 30 seconds globallyIncluded in plan; per-zone quotas
FastlyPurgeURL or Surrogate-KeySurrogate-Key (free, all tiers)~150 ms (instant purge)Included in usage; batch API for keys
Google Cloud CDN / Media CDNInvalidatePath + wildcardCache tag (response header)A few minutesFirst entries free per month; usage-based above
Edgio (Verizon Digital Media)PurgeURL, list, dirSurrogate keysA few secondsIncluded; live and on-demand purge endpoints
Three nuances worth pinning to the wall.

The cache-tag operation is what changed in this market. Fastly shipped surrogate keys in 2014 and has had a decade-long advantage for streaming teams who needed to group thousands of segments under one tag and purge the group in a single request. Akamai and Cloudflare followed. CloudFront added Cache Tag invalidation in April 2026 — five-second propagation at P95, response-header-driven, the same model Fastly pioneered. Streaming workloads on AWS that were stuck doing path-by-path invalidations have a more elegant tool now.

The propagation time is best-case, not worst-case. CloudFront's 10–15 minute number for path invalidations is the documented expectation; tickets to AWS support routinely show longer tails for distributions with many edge locations. Fastly's 150 ms is genuine but applies only to nodes that received the purge — a node currently being added to a POP can serve stale for longer. Plan as if the tail is two to three times the documented number.

You can be rate-limited. CloudFront throttles when too many invalidations are in flight (the TooManyInvalidationsInProgress error). Akamai and Cloudflare publish per-account per-minute caps. A team that scripts "purge on every deploy" eventually hits the wall during an actual incident.

The two pitfalls that quietly break production

Pitfall — fix origin first, invalidate second. An invalidation against a still-broken origin pulls the bad content right back into cache, costing you an invalidation for nothing. The order is always: stop the origin from serving the bad file, then invalidate. For takedowns that means deleting (or 410-ing) the asset at origin first.
Pitfall — wildcard scope drift. A /series-7/* invalidation looks tight; a /* invalidation aimed at a single typo collapses the global cache hit ratio of every other asset on the distribution for the next half hour. CloudFront's own guidance is "specify the path only to the files that you really need to invalidate." Build a guardrail in the deploy pipeline that rejects any path containing more than one trailing wildcard.

A third one is worth a sentence even though it is less common: invalidations against URLs that carry signed-URL query parameters can fail to match anything if your cache key includes the signature. Article 6.3 — Cache keys for streaming covers the cache-key half of that problem in full.

Two tables ranking the four tools by how fast a change reaches viewers. The first table covers tools 1 to 3, designed in, with no operator action and no purge: 1, short Cache-Control TTL, where manifests expire on schedule and players refetch, taking the configured TTL; 2, versioned segment filenames, where a new URL is a cache miss by definition, instant for new URLs; 3, segment-timeline rolloff for live, where the packager drops the segment and the CDN copy ages out, one playlist refresh. The second table covers tool 4, real CDN invalidation, paid, rate-limited and a last resort: 4a, Fastly instant purge with surrogate keys that group thousands of segments under one key, about 150 ms global; 4b, CloudFront Cache Tag from April 2026, response-header tags that count in the path budget, under 5 s at P95; 4c, Akamai Fast Purge by URL, CP code, ARL or Edge-Cache-Tag header, about 5 s; 4d, Cloudflare purge by tag on Enterprise, by URL, prefix, hostname or Cache-Tag header, under 30 s globally; 4e, Google Cloud and Media CDN invalidate by path, wildcard and cache tag, usage-priced, a few minutes; 4f, CloudFront path invalidation by path and wildcard, 1,000 per month free then $0.005, 10 to 15 minutes. Closing lines say tools 1, 2 and 3 cover about 95% of changes and tool 4 is left for key rotation, takedown, a bad asset and live pullback. Figure 3. Where each tool sits on the cost × latency × precision plane. ↓ Free download: Cache Invalidation PlaybookOne page for the next incident: the four streaming cache-control tools in the order you should reach for them, the four use cases that actually earn an invalidation, and the pre-flight checks to run before anyone clicks purge.

Where Fora Soft fits in

Most of our streaming, OTT, e-learning, telemedicine, and surveillance clients hit a cache-invalidation question within the first six months of going live — typically a takedown request, a key-rotation flow, or a botched ladder deploy. We design the four-tool playbook into the platform up front: short max-age on manifests, immutable versioned segments, segment-timeline-driven rolloff for live, and a guarded invalidation path that requires both a fix-at-origin step and a wildcard-scope review. The same scaffolding underpins our DRM and compliance work, where the difference between "we purged everything" and "we purged the right thing" is the difference between a clean incident report and a six-figure CDN bill. It ships as standard in the OTT and IPTV platforms we build and in our wider video streaming software development for live and VOD.

Video Streaming: A Complete Guide to Video Delivery - From ABR and CDNs to Players, WebRTC, DRM, and the Economics of Streaming - book cover

The book

Video Streaming: A Complete Guide to Video Delivery: From ABR and CDNs to Players, WebRTC, DRM, and the Economics of Streaming

We wrote a seven-volume handbook that takes the whole video stack apart, from the pixel to production, so that someone who works through it can design and build a delivery pipeline that rarely needs the purge button. Volume 3 is where caching lives: what the edge actually stores, how cache keys and TTLs decide your hit ratio, origin shielding and tiered caching, and the delivery economics that turn one careless wildcard into a month of extra CDN bill. Volume 2 covers the packaging and manifest formats behind tools 2 and 3 here — HLS, MPEG-DASH and CMAF, and the segment timelines that do the invalidation work for you. Written by Nikolay Sapunov, CEO at Fora Soft.

Read it on Amazon →Kindle & paperback · Fora Soft Video Engineering Handbook

Is the purge button a habit on your team, or a last resort?

Send us the Cache-Control headers you ship today, how your manifests and segments are named, and the last three times somebody purged. We will tell you which of the four tools your pipeline is missing, where a wildcard can take the hit ratio of every other asset down with it, and what a guarded invalidation path looks like in a deploy pipeline — fix-at-origin step, scope review, and all. 250+ video products shipped since 2005.

Book a 30-min call →WhatsApp →Email us →

See our case studies

Case study

Worldcast Live

HD concerts at 1.5 Gb/s and 0.4–0.5 s glass-to-glass for 10,000 simultaneous viewers. On a live show nothing is ever purged in time: the segment timeline rolls the bad part off the playlist while a global purge would still be propagating.

Case study

Mindbox

An AI video management system with 50+ deployments, pulling RTSP from cameras through FFmpeg into HLS. Recorded footage has to disappear on request — the takedown case from this article: remove it at origin first, then invalidate the prefix.

Case study

Sprii

A live shopping platform with 72,000+ streamed events and €365M in sales over RTMP and WebRTC. Overlays and replays keep changing after a show ends, and versioned paths absorb all of it without a single call to the purge API.

References

  1. Amazon Web Services. CloudFront Developer Guide — Invalidate files to remove content. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html (accessed 2026-05-24).
  2. Amazon Web Services. CloudFront Developer Guide — Pay for file invalidation. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PayingForInvalidation.html (accessed 2026-05-24). First 1,000 paths/month free; $0.005 each above.
  3. Amazon Web Services. Manage caches with precision using Amazon CloudFront Invalidation by Cache Tag. Networking & Content Delivery Blog, April 2026 — 5-second P95 propagation; tag-based invalidation header model.
  4. Fastly Documentation. Purging with surrogate keys. https://www.fastly.com/documentation/guides/full-site-delivery/purging/purging-with-surrogate-keys/ (accessed 2026-05-24).
  5. Fastly Documentation. Streaming configuration guidelines. https://www.fastly.com/documentation/guides/full-site-delivery/video/streaming-configuration-guidelines/ (accessed 2026-05-24).
  6. Cloudflare Documentation. Purge cache by tag / Cache-Tag header (Enterprise). https://developers.cloudflare.com/cache/how-to/purge-cache/purge-by-tags/ (accessed 2026-05-24).
  7. Google Cloud Documentation. Media CDN — Invalidate cached content. https://docs.cloud.google.com/media-cdn/docs/cache-invalidation (accessed 2026-05-24).
  8. Akamai TechDocs. Fast Purge API v3 reference. https://techdocs.akamai.com/purge-cache/reference/api (accessed 2026-05-24).
  9. IETF. RFC 9111 — HTTP Caching, June 2022. Sections 4.4 (Invalidation) and 5.2 (Cache-Control). Replaces RFC 7234.
  10. IETF. RFC 8246 — HTTP Immutable Responses, September 2017. Definition of the immutable Cache-Control extension.
  11. IETF. RFC 8216 — HTTP Live Streaming, August 2017. §4.4.4 (EXT-X-KEY), §6.2.2 (sliding window of media playlists).
  12. Apple. HTTP Live Streaming (HLS) Authoring Specification for Apple devices, revision 2025-09. Manifest-freshness and segment-availability guidance.
  13. ISO/IEC. 23009-1:2022 — Information technology — Dynamic adaptive streaming over HTTP (DASH). Annex describing SegmentTimeline and dynamic MPD updates.
  14. DASH-IF. Implementation Guidelines: Restricted Timing Model. https://dashif-documents.azurewebsites.net/Guidelines-TimingModel/ (accessed 2026-05-24). Live MPD timeline updates and period removal.
  15. ISO/IEC. 23001-7:2023 — Information technology — MPEG systems technologies — Part 7: Common encryption in ISO base media file format files. Key-rotation provisions cited by streaming DRM implementations.
  16. W3C. Encrypted Media Extensions — Candidate Recommendation Snapshot 2024-11-05. https://www.w3.org/TR/encrypted-media/ (accessed 2026-05-24).
  17. Unified Streaming Documentation. Caching recommendations — Cache invalidation/purge. https://docs.unified-streaming.com/best-practice/caching/recommendations/configuration/cache-invalidation.html (accessed 2026-05-24).