Choosing Between URL Versioning and CDN Purge APIs for JAMstack Cache Invalidation

Answer to the question

1. Provider X automatic purge – A new deployment triggers an implicit purge of every cached asset that is part of the deployment payload. The purge is scoped to the exact paths that were included in the build output; assets that were not redeployed remain cached. Therefore, for resources that *are* redeployed, URL versioning is redundant, but for third‑party libraries or static assets that live outside the deployment tree, URL versioning is still useful to force a cache miss.

2. Provider Y bulk purge – The bulk‑purge endpoint accepts a list of URLs or a wildcard pattern. It is capped at 100 purge requests per minute, and any purge beyond the free tier incurs a per‑operation fee. Bulk purges are cheaper than issuing many individual purge calls, but they still consume quota and can be throttled if you exceed the minute limit.

3. URL versioning overhead – Adding a hash or timestamp to the filename creates a new cache key for each updated resource. While this guarantees a fresh fetch, it inflates the cache footprint and can dilute cache hit ratios, especially for large assets that change infrequently.

4. Multi‑provider workflow – The safest strategy is to let provider X’s automatic purge handle all redeployed files, use URL versioning for assets that are not part of the deployment payload (e.g., CDN‑cached libraries), and call provider Y’s bulk purge only for resources that cannot be versioned or that require an explicit invalidate. A post‑deploy health check that fetches a known updated asset via both its original and versioned URLs confirms that the CDN is serving the latest content.

Confirmed facts

• Provider X purges only the files present in the deployment payload.
• Provider Y’s bulk purge rate limit is 100 requests per minute.
• Bulk purges cost money beyond a free tier threshold.
• URL versioning creates a new cache key for each updated resource.
• URL versioning does not affect assets that are redeployed if provider X already purges them.

Best‑practice explanation

1. Track deployment payload – Maintain a manifest of all files that are part of each build. This tells you exactly which assets provider X will purge automatically.
2. Apply URL versioning only to non‑deployed assets – For third‑party libraries or static files that live outside the build tree, append a hash or timestamp to the filename.
3. Use provider Y bulk purge sparingly – If you need to invalidate a large number of URLs that cannot be versioned, batch them into the fewest possible bulk requests and stay below the 100‑req/min limit.
4. Post‑deploy health check – After each deployment, fetch a known updated asset using both the original and the versioned URL. Verify that the response matches the latest build hash. If the original URL still returns stale content, trigger a manual purge via provider Y.
5. Centralize mapping – Store a mapping of which assets are covered by automatic purge, which are versioned, and which rely on bulk purges. Use this map to generate purge payloads and to detect overlaps that could cause stale content.

Missing diagnostic detail

To fine‑tune the strategy, could you confirm whether provider X’s automatic purge also clears cached files that share the same base path but were not redeployed (e.g., /assets/js/* when only /assets/js/main.js is updated)? This detail will determine if URL versioning is still needed for sibling files.