Transloadit

What is Cache Invalidation?

Cache invalidation removes cached entries or marks them stale before their normal expiration. Later requests trigger a new fetch or a revalidation with the origin, and an entry that was only marked stale may still be served in the meantime, depending on cache policy.

How Cache Invalidation works

Invalidation changes cache state without requiring publishers to wait for freshness lifetimes to elapse. HTTP itself offers little for this: a cache invalidates a URL when a successful unsafe request such as PUT, POST, or DELETE for it passes through, which affects only the caches on that request’s path, and no Cache-Control directive can clear a response that is already stored. CDNs therefore expose their own control plane, which may target exact URLs, prefixes, tags, or an entire distribution, after which affected nodes evict the object or require revalidation. A hard purge removes the object, so the next request for it is a cache miss that is fetched in full and cached again. A soft purge keeps the object and marks it stale, so the next request revalidates it and can reuse the stored body when the origin answers 304 Not Modified. Provider names differ: Cloudflare calls the soft operation invalidation and the hard one purge, while what Amazon CloudFront and Google Cloud CDN call an invalidation removes the object.

Key facts

  1. Does purging the original URL also remove its resized or reformatted variants? Only if the provider treats them as one object or you target them together, so start from how the variant URLs differ from the original. On Fastly CDN services, Image Optimizer purges the original and every variant when the purge request carries no transformation parameters; on Fastly Compute services the same set is purged through the Purge API by a shared surrogate key. Cloudflare purges all cached variants of an image URL that uses its Vary for Images feature. Amazon CloudFront, by contrast, requires the query string in the invalidation path when the distribution forwards query strings to the origin, or a trailing * wildcard to cover every query string. A purge that names one URL does not reach variants published under other paths, and whether it covers other hostnames depends on the provider: a Google Cloud CDN path invalidation applies to every hostname on the load balancer unless a host is specified. Variants outside the selector need a shared cache tag or surrogate key, a prefix purge, or an explicit list.
  2. In what order, and how do I know it worked? Correct the content at the origin first: Cloudflare and Google Cloud CDN both warn that otherwise the next request can cache the old version again. A successful API response is not proof of removal. Cloudflare documents that HTTP 200 from a purge request confirms receipt, not that anything was cached or evicted, and says to request the asset and confirm that CF-Cache-Status is no longer HIT. That header is supporting evidence, not proof: the first request after a purge reports MISS and later ones report HIT for the refilled copy, while STALE or UPDATING means an expired stored copy was served. Request the original and each affected variant with a client that has no local cache, and confirm that the returned content is the replacement. Each response describes one cache: Google Cloud CDN notes that an invalidation can be reported as complete while a small number of caches have not yet processed it, a rare state that corrects itself. On CloudFront a submitted invalidation cannot be canceled, so check the paths before sending it.
  3. Does a CDN purge update what browsers hold? No. Google Cloud CDN states that invalidations do not affect copies in web browser caches or in caches operated by third-party internet service providers, and the CloudFront guide says a user might keep seeing the old version until it expires from those caches. To get past those copies sooner, publish the corrected file under a new file name or path and update the pages that reference it, which is one reason CloudFront recommends versioned file names over invalidation for files that are updated frequently. Copies stored under the old URL are not removed: pages that reference the new URL simply stop requesting them. Changing only the query string is weaker, because it works only where every cache on the path includes the query string in its cache key; under Cloudflare’s Ignore Query String cache level, for example, URLs that differ only in the query string share one cached object. A URL that has to stay the same and may need correcting in place should not carry a long browser lifetime.
  4. Hard purge or soft purge, and how much? After a hard purge of everything, requests are served from the origin until the cache is repopulated; Cloudflare warns that on high-traffic sites with many assets this can cause a large spike in origin requests, slow the site down, and overload the origin, and Google advises invalidating only what you must. A soft purge lets the next request revalidate and reuse the stored body, which only works if the origin sends ETag or Last-Modified and answers conditional requests; Cloudflare suggests it for refreshing content that might not have changed, such as a group of assets that share a cache tag. The trade-off is that stale-marked content can still reach viewers: Fastly describes a soft-purged object as served stale while the updated one is fetched, and Cloudflare can serve invalidated content stale when the origin returns a 5xx error or is unreachable. Use a hard purge when the old content must never be served again. Request collapsing and an origin shield tier reduce how many refill requests reach the origin.

When Cache Invalidation matters

Invalidate an asset when an urgent correction must propagate before its time-to-live expires. An invalidation at a CDN does not reach copies that browsers or other downstream caches already hold, so content that changes routinely is better published under versioned file names. Purge the narrowest set that covers the change, because everything a broad purge removes has to be refilled from the origin as requests arrive.

How Transloadit helps with Cache Invalidation

Transloadit’s Smart CDN caches each transformed result under its tlcdn.com URL. The documentation describes controls that bound in advance how long a result is reused: the cache_duration parameter of the /file/serve Robot sets the browser and shared-cache lifetimes sent with the result, and for signed URLs the effective cache lifetime is bounded by the remaining signature lifetime.

The pages linked here do not describe a purge or invalidation operation for Smart CDN, or what happens to a cached result when the original is replaced under an unchanged file path. A Smart CDN URL names a source file and the transformation parameters that your Template reads, so a different file path or a different value for one of those parameters requests a different rendition. The pages do not say that an unrelated extra parameter bypasses a cached result; test the unchanged-path case on your own Workspace before relying on it.

Explore Transloadit’s delivery capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free