On Black Friday, a store’s problem is rarely a lack of servers. It is the request that reaches the origin when it didn’t have to, asking for a page or an image that a cached copy could have served. Every page served from the cache is one less request to the backend at peak time, which is why preparing your Black Friday cache usually pays off more than adding machines to the origin.
Here is how to do that preparation on Azion, from what goes into the cache to the purge plan for when prices change.
Why does Black Friday peak traffic reach the origin?
Two situations explain most of that traffic. The first is the empty cache at midnight, when the campaign opens and the first requests at each data center all go to the store’s origin server. The second is a TTL that is too short, which makes the copy expire and forces Azion to fetch content again even though it hasn’t changed.
When both are solved, the result shows in the Renner case: the retailer reached a peak of 899,000 requests per second on Black Friday, and, according to the success case, only a small percentage of them reached its origin infrastructure.
Every trip to the origin also adds response time, and latency in e-commerce hurts conversion even while the store stays online. Part of that traffic doesn’t even come from customers but from bots, which are also worth filtering before the peak.
What can and can’t go into the cache?
The rule is simple: what is the same for everyone goes into the cache, and what changes for each visitor stays out. The storefront, categories, product pages, images, CSS, JavaScript, and fonts are the same for any visitor and concentrate the campaign traffic. Cart, checkout, and login change with every session and keep going to the origin, and the post on how to prevent checkout failures during traffic spikes shows how to protect that part of the journey.
On Azion, this split is safe by default, because Cache stores nothing until a Rules Engine rule applies a cache setting to a path. You include what can be shared, path by path, and anything no rule mentions keeps going to the origin.
| Content | Example path | Goes into the cache? |
|---|---|---|
| Images, CSS, JS, and fonts | /static/*, /images/* | Yes |
| Storefront and category pages | /, /deals/*, /c/* | Yes |
| Product pages | /p/* | Yes, if price and stock aren’t personalized |
| Cart, checkout, and login | /cart/*, /checkout/*, /login | No |
If the product page shows a different price or stock level by cookie, it needs to vary the cache by that cookie, which requires Application Accelerator, or load that part through a separate call that bypasses the cache, as discussed in the post on why traditional caching fails at checkout.
What cache TTL should you use during Black Friday week?
The TTL is how long a copy is kept, and every Azion cache setting has two: one for the Azion cache and one for the browser. With Honor cache policies, the lifetime comes from the HTTP cache headers Cache-Control and Expires that the origin sends, and with Override cache behavior, the Max Age you set applies, as the expiration and freshness page explains.
For Black Friday, Override is the more predictable choice, and it is also required to turn on Tiered Cache. A starting point for a typical store:
| Content | Suggested cache TTL for the week | Note |
|---|---|---|
| Images, CSS, JS, and fonts | Days | Purge when the file changes |
| Storefront and category pages | Minutes | With Stale cache on |
| Product pages | Minutes | Purge when the price changes |
| Flash deals | A few seconds | Requires Application Accelerator |
On pages with prices, keep the browser TTL short, so that people who come back to the page don’t see an old price after a purge.
Without Application Accelerator, the minimum Max Age is 60 seconds. With it, you can micro cache pages that change often, such as a flash-deal storefront with a 10-second TTL. And when several requests for the same object arrive at once with no copy in the cache, Azion opens a single connection to the origin for all of them.
How does Tiered Cache reduce origin load?
Tiered Cache adds a second cache layer in front of the origin, hosted in the region that the cache setting’s topology defines. When a data center doesn’t have the object, it checks that layer before going to the origin, and an object fetched once from the origin then serves the other data centers from there, so the first request at each one doesn’t become a request to the store’s server.
To turn it on, the cache setting must use Override cache behavior and have a Max Age of at least 3 seconds with Application Accelerator, or 60 seconds without it, which is the floor for any cache setting. It is included in every plan, at the cost of one extra hop when the first layer doesn’t have the object, and the article What is tiered caching? explains this architecture in more detail.
What happens to the cache if the origin goes down?
With Stale cache on, Azion keeps serving the last copy it has when the origin responds with a 5xx error, times out, or is unreachable, and also while it fetches a new version, so visitors keep seeing the storefront instead of an error page.
This protection has a window of 300 seconds by default, or the stale-while-revalidate value the origin sends when the setting uses Honor cache policies, and once the window ends, expired pages depend on the origin again. For longer outages, Azion lets you distribute traffic across two or more origins with Load Balancer.
Check that Stale cache is on, because settings created through the API or the CLI start with it off. In responses, the STALE status means the origin failed and the expired copy was served, and UPDATING means a new version is on its way.
How do you warm the cache before the peak?
Warming the cache, or cache pre-warming, means making the first request to each page ahead of time so that a visitor doesn’t have to, and the Azion CLI has a command for it, azion warmup. It starts at a base URL, reads the links on each page it receives, and requests every new URL it finds, until the queue is empty or the command reaches its URL limit.
By default, the command sends 2 requests at a time, processes up to 1,500 URLs, and waits up to 8 seconds for each one. The base URL can include a path, so you can warm only the campaign section with limits tuned to it (--timeout is in milliseconds):
At the end, a summary counts the URLs that succeeded and the ones that failed. Since every page that isn’t cached goes to the origin, run the command during low traffic and raise --max-concurrent gradually.
Warming works better with Tiered Cache on, because a data center that doesn’t have the object checks that layer before going to the origin, and a page warmed there is then served from it to the other data centers. Timing also has to match the TTL, so an overnight warmup suits content that stays cached for a long time, such as images and static files, while short-TTL pages need warming right before the campaign opens and after each purge.
How do you update prices without emptying the whole cache?
On Black Friday, prices change by the hour, and Real-Time Purge removes objects from the cache by URL, by cache key, or by wildcard, through the Console, the API, or the CLI. The safest approach is to keep it ready in a script or in the pipeline that publishes prices.
With Tiered Cache on, purge the Tiered Cache layer first, which only accepts purges by cache key, and then the main cache, because in the reverse order a data center can fetch back the old copy still held in Tiered Cache:
A page’s cache key shows up in the x-cache-key response header when the request is sent with Pragma: azion-debug-cache, and that is the value the Tiered Cache purge needs. In the default cache key, the scheme, host, and path appear together with no separator, as in the example above. If the page varies by cookie, a purge by URL doesn’t reach those copies, and you need to purge each variation by cache key or use a wildcard ending in @@*.
A purge by URL or cache key accepts up to 50 objects per request and 10,000 every 60 seconds, and a wildcard purge accepts one expression per request and 2,000 requests every 24 hours. For a bulk price change, that favors purging a whole section by wildcard, such as www.yourstore.com/deals/*, and keeping purges by URL for individual products.
A purge is queued and propagates across Azion’s distributed infrastructure, and after it runs, running azion warmup on the purged section helps put the new copy in the cache before traffic asks for it again.
How do you know how much traffic comes from the cache?
Offload, the share of traffic served without fetching from the origin, is the number that sums up this preparation. In Real-Time Metrics, on the Applications tab, filter the dashboard by the store’s host and follow the Edge Offload chart and the Saved Data and Missed Data totals. On the Requests dashboard, the equivalents are Requests Offloaded, Saved Requests, and Missed Requests.
During the peak, the Missed Requests chart shows the requests the data center didn’t answer from its own cache. A jump right after a purge is expected, while a high, steady level usually points to a path with no cache rule or to a page that varies by something the cache doesn’t account for. With Tiered Cache on, what actually reaches the origin shows up on the Tiered Cache tab.
To test this setup before the peak, create a free account on the Hobby plan and build your application’s cache rules, or talk to an Azion specialist to plan your store’s cache for Black Friday.
Frequently asked questions
What does warming the cache mean?
It means requesting pages before visitors arrive, so the first copy is already stored when the peak begins. On Azion, azion warmup, from the Azion CLI, does this from a base URL by following the links on each page.
What TTL should you use for product pages?
Minutes, for most stores, with a purge whenever the price changes and a short browser TTL. If the page needs a TTL below 60 seconds, that requires Application Accelerator.
What happens to the cache if the origin goes down?
With Stale cache on, Azion keeps serving the last copy for up to 300 seconds by default, or for the stale-while-revalidate value the origin sends.
How do you update prices without emptying the whole cache?
Use Real-Time Purge by URL or cache key for individual products, and by wildcard for a whole section. With Tiered Cache on, purge Tiered Cache first and then the main cache.
How do you know how much traffic comes from the cache?
In Real-Time Metrics, the Edge Offload chart on the Applications tab shows the share of data served from the cache, and Requests Offloaded shows the share of requests.
How do you set up the cache for Black Friday on Azion?
Azion is a serverless platform that runs applications on a distributed infrastructure of data centers. The cache is configured with Rules Engine rules using the Set Cache Policy behavior, and Tiered Cache and Stale cache are turned on in the application’s cache settings.