Application Accelerator in the application request path

This design serves an application whose responses depend on more than the URL: an API that answers differently per query string, a catalog that differs per device, a page that varies per session. Application Accelerator puts those inputs into the cache key, so the cache can tell two correct responses apart instead of serving one of them to everyone or caching neither.

It suits teams whose dynamic paths reach the origin on every request because a URL-keyed cache cannot represent what makes those requests different.

The request path

1. A client requests a domain associated with the application. Workloads registers that domain with Azion.
2. The application receives the request in the nearest data center and Rules Engine evaluates its request-phase rules.
3. A rule decides what happens to the cache. Set Cache Policy applies a cache setting; Bypass Cache sends the request to the origin and caches nothing.
4. The cache key is built from the URL plus every variation the cache setting names: the allowed query string arguments, the named cookies, the device group, and, for a cached POST or OPTIONS, the MD5 hash of the request body.
5. A key already in the cache is answered from the stored object. A key that is not reaches the origin, and the response is stored under that key for the TTL the cache setting carries.
6. A request carrying the Pragma: azion-debug-cache header gets the key back in the X-Cache-Key response header, which is how you confirm the variation is the one you configured.

Two behaviors change the shape of this path rather than its steps. A Max Age of 0 seconds keeps the request on the cache path while collapsing simultaneous requests into one origin request, where Bypass Cache leaves the cache path entirely. For that difference, and for what each variation costs, refer to Cache variation.

Components

• Applications holds the delivery configuration, the cache settings, and the rules, and is where the Application Accelerator module is turned on.
• Cache holds the objects and owns the cache key format that every variation appends to.
• Rules Engine decides which requests a cache setting covers, and carries the behaviors this module unlocks.
• Application Accelerator supplies the cache variation, the caching of POST and OPTIONS responses, and the cache TTL below 60 seconds.
• Workloads registers the domain that serves the application.

Implementation

1. Create an application, in Azion Console, through the Azion API, or with Azion CLI. For the steps, refer to Applications quickstart.
2. Register the domain that serves it. For the steps, refer to Add a custom domain to a workload.
3. Turn on Application Accelerator and create a cache setting that varies by the attribute your responses depend on. For a query string or a cookie, refer to Configure Advanced Cache Key for an application. For a POST response, refer to Cache POST and OPTIONS responses.
4. Apply the cache setting with a Rules Engine rule, and add any bypass or cookie-forwarding rule the design needs. For the steps, refer to Configure cache policies for an application.
5. Point your domain’s CNAME record at the Azion endpoint for that domain.
6. Confirm the variation with the Pragma: azion-debug-cache header, then watch the cache status over real traffic and adjust the variation rather than the TTL when the cached object count grows faster than the content.

Plan the purge alongside the variation. A URL purge does not reach objects that vary by cookie or device group, so those need a cache key purge or a wildcard purge. For the purge types, refer to Real-Time Purge.

Related resources