# Cache variation When the response to one URL depends on a cookie, a device, or a request body, the cache has to tell those requests apart. On an application, one switch turns on Application Accelerator, and a cache setting then names the inputs that make two requests different. How a variation changes the cache key, with its diagram, is on [How Applications works](/en/documentation/platform/applications/how-it-works/#application-accelerator). The sections cover what the switch unlocks, what a variation costs, how purges reach variations, and how *Bypass Cache* differs from a TTL of 0. --- ## What Application Accelerator unlocks Turning on Application Accelerator unlocks four capabilities that look unrelated until you see what they have in common: - Cache variation beyond the URL, by query string, by cookie, by device group, and by request method. The feature is named [Advanced Cache Key](/en/documentation/platform/applications/cache/cache-settings/#application-accelerator). - Caching of `POST` and `OPTIONS` responses, beyond the `GET` and `HEAD` responses an application caches natively. - A **Max Age** as low as 0 seconds, under the 60-second floor that holds without it. - Seven more Rules Engine behaviors, and the `${request_uri}` and `${device_group}` variables in rule criteria. The behaviors are *Add Cookie*, *Bypass Cache*, *Capture Match Groups*, *Filter Request Cookie*, *Forward Cookies*, *Rewrite Request*, and *Run Function*. What the four have in common is dynamic content. Cache variation gives the cache key the extra input it needs to tell two correct responses apart. Caching `POST` and `OPTIONS` brings in the methods that carry that input in the request body. A TTL under a minute fits content that stops being correct before a minute passes. Several of the gated behaviors act on the cookies and paths that carry the difference in the first place. The switch is all four or none. An application cannot take cache variation without also taking the extra methods and behaviors. A cache setting that sets a variation on an application with the switch off is refused with `21013`. Turning the switch on changes no traffic by itself, either. The query-string, cookie, and device controls of a cache setting start at `ignore`, and the method list starts empty. A cache setting reaches a request only when a [Set Cache Policy](/en/documentation/platform/applications/rules-engine/#set-cache-policy) behavior applies it. Turning on a Product can generate usage-related costs. For more information, refer to [Pricing](/en/documentation/fundamentals/pricing/#application-accelerator). --- ## The cost of a variation Cache variation has one cost, and it follows from how the key is built: each distinct value of a varying attribute produces a separate cached object. That makes the choice of what to vary by more consequential than the choice to vary at all. A cookie whose value is unique to each visitor gives every visitor a copy of the object. The cache still works, but it no longer serves one stored response to many requests, and the number of objects grows with the audience instead of with the content. An allowlist is the control for that cost. The `allowlist` behavior names the query-string arguments or the cookies that change the response, so an attribute nobody named cannot create another object. The `all` behavior varies by every attribute that arrives, including the ones the application ignores. For example, a link that arrives with a campaign argument gets its own cached object under `all`. Under an allowlist that does not name that argument, the same link maps to the shared object. Sorting applies the same economy to the order of the arguments. The chosen arguments enter the key in the order the request submitted them, so `?a=1&b=2` and `?b=2&a=1` are two objects that hold one response. With **Sort** on, those variations group under one key, ordered alphabetically. For example, a product listing that changes with its `category` and `page` arguments names both in an allowlist. With **Sort** on, every order of the two arguments reaches one object. The cost of sorting is that the key no longer matches the URL as the client wrote it, which matters at purge time. For the Console steps that set these controls, refer to [Configure Advanced Cache Key for an application](/en/documentation/guides/application-performance/cache-and-purge/advanced-cache-key/). --- ## Cache variation and purges A purge removes an object from the cache, and it finds the object by its cache key. A URL purge converts the URL it receives to a cache key without considering content variation. Every variation that the URL does not carry therefore survives it. Cookie variations and device group variations do not expire with a URL purge, and their copies stay in the cache. Two purge types reach them. A cache key purge names each variation, and a wildcard purge ends the key with `@@*`. Query-string variations are the exception, because the query string is part of the URL. A URL purge reaches them when the arguments are sent in the order they were presented, or in alphabetical order when **Sort** is on. The variations you configure are also the objects a purge has to reach. A variation with many distinct values therefore costs you at purge time as well as in storage. For the purge types and the steps to run each one, refer to [Real-Time Purge](/en/documentation/platform/applications/cache/real-time-purge/#purge-content-that-varies). --- ## Bypass Cache and a TTL of 0 Without Application Accelerator, the shortest **Max Age** an application accepts is 60 seconds, and the API refuses a lower value with `21021`. Application Accelerator removes that floor and allows 0 seconds, or 3 seconds when the cache setting also has Tiered Cache on. A TTL of 0 is not the same as not caching, and the difference between the two is why both exist. Both need Application Accelerator, because *Bypass Cache* is one of the behaviors it unlocks. The [Bypass Cache](/en/documentation/platform/applications/rules-engine/#bypass-cache) behavior sends every HTTP and HTTPS request its rule matches to the origin, and Azion caches nothing in its own cache. It keeps protocol optimizations and, where possible, a keep-alive connection to the origin. It does not change the browser cache, which a *Set Cache Policy* behavior sets. It does not reach the Tiered Cache layer either: an application with active Tiered Cache settings keeps caching objects there for the minimum TTL. Use it when each request has to receive different content. A **Max Age** of 0 seconds keeps the request on the cache path. Parallel requests for the same object reach the origin as one request, and Azion validates the object with an `If-Modified-Since` request. An object that has not changed is not transferred again, and the answer can be a `304 Not Modified`. A **Max Age** of 0 still creates a cache object, which lives for 999 milliseconds. Use it when dynamic content can be delivered identically to everyone who requests it at the same moment. The trade is between freshness for each request and load on the origin. *Bypass Cache* gives every request its own answer, and gives up both the single origin request for parallel requests and the revalidation that skips an unchanged transfer. A TTL of 0 keeps both, and gives up the ability to answer two simultaneous requests differently. --- ## Related resources - [Application Accelerator settings](/en/documentation/platform/applications/application-accelerator/settings.md): The controls behind cache variation, cached POST and OPTIONS responses, and a TTL under the floor. - [Configure Advanced Cache Key for an application](/en/documentation/guides/application-performance/cache-and-purge/advanced-cache-key.md): The Console steps that set the variation controls of a cache setting, including Sort. - [Cache POST and OPTIONS responses](/en/documentation/guides/application-performance/cache-and-purge/cache-post-and-options-responses.md): The steps that turn on caching for the two methods Application Accelerator adds. - [Application Accelerator quickstart](/en/documentation/platform/applications/application-accelerator/quickstart.md): The switch turned on and a first cache setting that varies.