# Real-Time Purge **Real-Time Purge** allows you to instantly delete the cache of your content at Azion. When you update content at your origin, you must choose the best strategy for updating it in Azion's cache. When configuring your cache policies, you determine the amount of time you want your objects to be cached at Azion. When you update your content at the origin, Azion can continue providing a cached copy for as much time as you have set it to be cached. With Real-Time Purge, you can instantly delete the cache of your content at Azion, from either **Cache** or **Tiered Cache**. This way, Azion system fetches the latest version of your content in the origin. However, if specific cached objects must be removed at the edge before they expire, you have the option to purge cache with Real-Time Purge. Regular cache purging as part of your application helps you: - Ensure that users receive the most up-to-date content and experience the latest changes to your application. - Prevent users from seeing obsolete content. - Deliver content that is compatible with modern browsers and devices. - Provide dynamic content caching and API responses without sacrificing the user experience. - Control how your objects are served by Azion. - Manage obsolete or outdated objects, helping your developers to build reliable, resilient, and better performing solutions. --- ## Best practices To ensure safe and controlled cache purges, you should maintain version markup in an object name. When you update the object at your origin, you can add the version in the object name, forcing each modification of your content to be treated as a new object by Azion. To version your objects, you can use a sequential number, a timestamp, or other mechanism that you think is most appropriate as a version markup. For example, instead of naming an image as `image.jpg`, you could name it `image_1.jpg` and, when you need to update it, change the version to `image_2.jpg`. This way, each content update will be treated as a new object by Azion, which allows you to control which object a request should return, even if the user has the previous version locally saved in the browser cache or in some intermediate cache. You'll also be able to provide different versions of your objects to different users and simplify the rollback process in case of issues with your update. ### `DEL` method If you use the `DEL` method to remove the object from the cache instead of **Real-Time Purge**, the user's first `GET` request will be made to the origin. However, this method prevents Azion from delivering [stale objects](https://www.azion.com/en/documentation/products/build/applications/cache/#stale-cache) if the origin is inaccessible, delivering an error page instead. You can use the `DEL` if your goal is to: - Remove content from Azion's cache after it has been removed from the origin. - Force the removal and later update of contents for which a timestamp is unreliable. - Force the delivery of an error page instead of a stale object if your origin is inaccessible and Azion is unable to get the latest version of your content. --- ## Layer **Real-Time Purge** offers you two layers to purge your cache from: - **Cache**: purges cache kept with Azion at the edge. - **Tiered Cache**: purges cache from the second layer at the edge. Can only be done when the [Tiered Cache](/en/documentation/products/build/applications/cache/tiered-cache/) module is active. --- ## URL purge Purges cached objects by entering a list of URLs as an argument. A URL purge is non-recursive, which means that only the URLs entered will be purged from the cache. The URLs are automatically converted to their respective cache keys, without considering any content variation in the same URL. :::note Content variations based on cookies, device groups, image format, or others don't expire with this operation. Consider using [cache key](#cache-key-purge) or [wildcard](#wildcard-purge) purge for these situations. ::: The expiration of content variations based on query string can be run using URL purge, since a query string is a component of the URL, as long as the arguments used for content variation are sent in the correct order in which they were presented. If you enabled [Query String Sort](/en/documentation/products/build/applications/cache-settings/#cache-by-query-string), either sort the arguments in the request, or consider using cache key purge or wildcard purge as an alternative. ### URL purge arguments The URL format must respect the standard: `scheme://host` or just `host`, followed or not by a `/path` and the `?query-string`. When the scheme isn't informed, both HTTP and HTTPS contents will be purged. :::caution If you use the asterisk (`*`) character in a URL purge request, it'll be treated as a character in the URL and not as a wildcard. ::: For example: - `http://www.yourdomain.com` - `http://static.yourdomain.com/include/site.css` - `https://static.yourdomain.com/include/site.js` - `dynamic.yourdomain.com/app.py?argument` --- ## Cache key purge Purges cached objects by passing a list of [cache keys](/en/documentation/products/build/applications/cache/#cache-keys) as an argument. You can specify an advanced cache key to identify different variations of an object, based on: - Query string or query string sort arguments. - Cookies when using [Advanced Cache Key](/en/documentation/products/build/applications/cache-settings/#advanced-cache-key). - Image format according to browser support when using [Image Processor](/en/documentation/products/build/applications/image-processor/). To purge all variations, you must search for the cache keys individually. --- ## Wildcard purge Purges cached object by giving a wildcard expression as an argument. ### Wildcard purge arguments The wildcard expression format must be according to the standard: `scheme://host` or just `host`, followed or not by a `/path` and the `?query-string`, with an asterisk character (`*`) in the `path` or query string. You can even use multiple wildcards to match a complex pattern of a `path`. For example: - `www.yourdomain.com/*` - `static.yourdomain.com/include/*.css` - `static.yourdomain.com/*/site.js` - `static.yourdomain.com/static/images/image_1.jpg?ims=*` - `www.yourdomain.com/alpha*` - `www.yourdomain.com/*beta*` - `www.yourdomain.com/*a*/charlie` - `www.yourdomain.com/*a*/*a*` - `www.yourdomain.com/*?b*` - `www.yourdomain.com/*?*2*c=*` :::note You can't purge from the **Tiered Cache** layer using a wildcard expression. ::: --- ## Application Accelerator purge You can purge objects with content variation based on cookies or query strings using the **Advanced Cache Key** feature from the [Application Accelerator](/en/documentation/products/build/applications/application-accelerator/) module. To remove objects with [cookie-based variation](/en/documentation/products/build/applications/cache/#advanced-cache-key), you can use a purge by cache key, entering all variations individually, or a purge by wildcard, using `@@*` at the end. To purge objects with [variation based on query string](/en/documentation/products/build/applications/cache/#advanced-cache-key), you can use: 1. A cache key purge, entering all the variations individually. 2. A wildcard purge, using `?*` at the end. 3. A URL purge, entering only the arguments used in the cache key in the URL. If you use **Query String Sort**, the arguments must be sent in alphabetical order. --- ## Image Processor purge You can purge images that are treated by [Image Processor](/en/documentation/products/build/applications/image-processor/). In addition to `host` and `path` the cache key must include the separator `?`, key-value pairs related to the type of processing, and the `@@` separator for identifying image format variation supported by the browser. For example: - `httpstatic.yourdomain.com/static/images/image.jpg@@` - `httpstatic.yourdomain.com/static/images/image.jpg@@webp` - `httpstatic.yourdomain.com/static/images/image.jpg?ims=88x@@` - `httpstatic.yourdomain.com/static/images/image.jpg?ims=88x@@webp` You can use a cache key purge, entering all variations individually, or a wildcard purge, using `*` at the end. --- ## Large File Optimization purge If you use the [Large File Optimization](/en/documentation/products/build/applications/cache-settings/#large-file-optimization) feature in your application, large files might still remain in cache. To perform a purge in this case, you must list the cache keys for each fragment individually. :::caution When purging individual fragments, your content might be liable to issues in case there is a change of content at the origin and outdated fragments remain in cache. ::: To purge all file fragments using this optimization, you can use a [wildcard](#wildcard-purge) purge: - `static.yourdomain.com/media/file.mp4*` --- ## HTTP method purge By default, Azion allows caching of `GET` and `HEAD` methods only. You can enable `POST` or `OPTIONS` caching with the [Application Accelerator](/en/documentation/products/build/applications/application-accelerator/#support-for-http-methods) module. To purge these objects, you can either use a [cache key purge](#cache-key-purge), entering all variations individually or a [wildcard purge](#wildcard-purge), using `@@*` at the end. --- ## Purge confirmation After creating a new purge, you'll receive a successful message to confirm the creation. Then, the purge is queued for execution and will appear in the history once completed. This happens because the results may take some time to propagate to all edge nodes. When necessary, you can query the purge history to filter the user who made the purge, the time, argument list, purge type, and method. --- ## Limits :::tip **Increase limits**

You can request to increase the limits based on your plan. Contact the [technical support team](/en/documentation/services/support/) to request it. ::: These are the **default limits**: | Scope | Limit | | --- | --- | | Number of requests in history | 1,000,000 | | Purge history time | 6 months | | URL and Cache Key size | 4,096 characters | | URL and Cache Key (operations per client)| 200 requests with 50 objects per request | | URL and Cache Key (Operations per minute) | 10,000 objects every 60 seconds | | Wildcard - Operations per day (24h interval) | 2,000 requests | | Wildcard size | 256 characters | | Wildcard per request| 1 | These are the **default limits** for each Support service: | Scope | Developer | Business, Enterprise, and Mission-Critical | | --- | --- | --- | | Purge operations | 1,000 per month | 1,000 per month
Additional purge operations are negotiable | :::tip **Increase limits**

You can request to increase the limits based on your plan. Contact the [technical support team](/en/documentation/services/support/) to request it. :::