Tiered Cache | How to Reduce Origin Load in Checkout and APIs

Learn how Tiered Cache and Selective Caching reduce origin load, increase cache hit ratio, and protect transactional flows during traffic spikes.

Traditional cache protects the origin under normal conditions. But during traffic spikes — when checkout performance is most at risk, it’s not enough. Tiered Cache adds intermediate layers between the user and the backend, consolidating requests and increasing cache hit ratio. Selective Caching complements this strategy by precisely defining what should be cached — and with what rule. Together, they reduce costs, protect the origin, and maintain stable conversion under extreme demand.


Introduction

Traditional cache solves the static content problem well. For e-commerce at scale, it’s not enough.

During traffic spikes, it’s not enough to store responses close to the user. You need to decide how many layers to distribute this cache across and what rules determine what will be stored. Without this control, the origin receives load that could be avoided — and checkout starts degrading exactly when purchase intent is at its peak.

Tiered Cache and Selective Caching answer these two questions. This article explains how each strategy works, when to combine them, and what real impact they have on checkout performance and transactional APIs.


1. What is Tiered Cache?

Tiered Cache is a multi-layer cache strategy that introduces an intermediate storage level between distributed points of presence and the origin server.

In a traditional architecture, when a node in distributed infrastructure doesn’t find data in cache, it queries the origin directly. In a Tiered Cache architecture, it first queries an intermediate layer — a centralized cache shared between multiple points.

This changes traffic behavior significantly:

  • requests from multiple geographic points are consolidated
  • the origin receives far fewer direct queries
  • global cache hit ratio increases
  • egress cost drops

Tiered Cache answers a specific question: “How many layers should I distribute cache across to reduce origin load?“


2. How Tiered Cache works in practice

The flow of a request in a Tiered Cache architecture works like this:

Level 1 — Local point of presence The request arrives at the node closest to the user. If the data is in local cache, it’s delivered immediately.

Level 2 — Intermediate layer (Tiered Cache) If local cache doesn’t have the data, the node queries the intermediate layer before going to the origin. This layer is shared between multiple points of presence.

Level 3 — Origin Only if the intermediate layer also doesn’t have the data does the request reach the backend.

This model has two immediate practical effects:

Request consolidation Multiple nodes that would need to query the origin independently now share a single response. The origin stops receiving redundant calls from different points.

Cache hit ratio increase Data not in local cache has a second chance to be found before reaching the origin. This increases the proportion of requests resolved without querying the backend.


3. What is Selective Caching?

Selective Caching — also called granular cache or advanced cache — is the ability to define what should be cached based on specific HTTP request information.

Unlike “all or nothing” cache, Selective Caching uses Advanced Cache Keys to segment stored content:

Cache by header Store different versions of a response based on headers like Device-Type, Accept-Language, or User-Segment.

Cache by cookie Accelerate personalized page fragments without mixing data from different sessions.

Cache by query string Treat search parameters, filters, or segmentation as cache differentiation criteria.

Selective Caching answers a different question than Tiered Cache: “What exactly should I cache — and with what rule?”

This distinction is important to avoid overlap with other cluster strategies. Micro Caching answers “how long to cache?”. Tiered Cache answers “how many layers?”. Selective Caching answers “with what selection criteria?”. These are different questions and complementary strategies.


4. When to use each strategy

Comparison table

DimensionTiered CacheSelective Caching
Central questionHow many layers to distribute cache?What to cache and with what rule?
MechanismIntermediate layer between nodes and originAdvanced Cache Keys by header, cookie, or query string
Main use caseTraffic spikes with multiple access pointsPersonalization, segmentation, A/B testing
Main benefitReduces direct calls to originAvoids delivering wrong data to wrong user
Risk if misconfiguredExtra latency in intermediate layerInvalidation complexity
Combines withSelective Caching, Micro Caching, stale-while-revalidateTiered Cache, key-based invalidation

When to use Tiered Cache

  • operations with multiple geographic access points
  • data with high concurrency and low variation
  • traffic spikes with concentrated request patterns
  • when egress cost needs to be reduced

When to use Selective Caching

  • responses that vary by user segment
  • APIs with different behavior by device or location
  • page fragments with partial personalization
  • flows that need cache without mixing session state

When to combine both

Combine Tiered Cache and Selective Caching when you need:

  • high efficiency across multiple layers
  • granular control over what each layer stores

In high-scale e-commerce, this combination is the standard for protecting the origin without sacrificing personalization.


5. What can and cannot be cached with these strategies

ResourceCacheable with Tiered + Selective?Recommended strategy
Product catalog✅ YesTiered Cache with key-based invalidation
Promotion previews✅ YesSelective by segment + short TTL
Shipping options by region✅ YesSelective by location header
Feature flags and configurations✅ YesTiered with controlled TTL
Payment method lists✅ YesSelective by market or segment
Payment authorization❌ NoAlways transactional
Order confirmation❌ NoAlways transactional
Cart-specific state⚠️ With careCache with key per session and fine invalidation

6. Real impact on checkout and APIs

Origin protection

When most requests are resolved in distributed layers, origin systems only handle essential transactional operations. Traffic growth stops translating directly into backend stress.

Transfer cost reduction

By serving more data in intermediate layers, data transfer costs drop significantly. Lojas Renner, after migrating to Azion’s distributed infrastructure, recorded a 67% reduction in data transfer costs.

Cache hit ratio increase

Marisa delivers more than 85% of their data directly through distributed infrastructure, saving on average 4.3 TB of bandwidth per day — with faster pages, lower costs, and stable conversions even during high-demand periods.

P99 stability

By consolidating requests in intermediate layers and reducing pressure on the origin, Tiered Cache directly contributes to keeping latency stable even under spikes — including the distribution tail, where the most affected users are.


7. Programmable resilience in practice

Tiered Cache and Selective Caching become even more powerful when part of a programmable resilience strategy.

This means you can:

Dynamically adjust during campaigns Modify cache policies in real-time, without new deploys. During a Black Friday event, this can be the difference between reacting to an incident at 11 PM or having the platform adjust automatically.

Combine with stale-while-revalidate While data is revalidated in the background, the user receives the cached version without perceiving any degradation. In partial origin failure scenarios, this preserves checkout availability.

Key-based purge instead of total purge When a price changes or a product goes out of stock, there’s no reason to invalidate the entire application’s cache. With key-based invalidation, you only clear the affected fragments — without impacting the rest of the performance.

// Example: tag-based invalidation with Azion Lib
import { purgeWildCard } from 'azion/purge';
async function purgePatterns(patterns, label) {
const { data, error } = await purgeWildCard(patterns);
if (error) {
console.error(`Purge failed for ${label}:`, error);
return { success: false, error };
}
return { success: true, invalidated: data?.items };
}

Advanced cache keys integrated into workflow Cache rules can be defined in code and updated in real-time, allowing teams to test personalization strategies, adjust policies by segment, and automate invalidations based on stock or promotions.


8. Real example: Lojas Renner on Black Friday

Lojas Renner is one of the most expressive cases of using distributed infrastructure to protect checkout during traffic spikes in Brazil.

Black Friday required an architecture capable of sustaining massive access spikes without degrading checkout for millions of consumers. To eliminate centralized bottlenecks, Renner migrated their applications to Azion’s distributed infrastructure, bringing execution closer to users and ensuring only critical transactional requests reached origin systems.

The results were:

MetricResult
Requests at peak maximum899,000 req/s
Image processing18,000 req/s
Transfer cost reduction67%
Stability on mobile and low-bandwidth regions✅ Maintained

Black Friday stopped being an infrastructure stress test and became a predictable revenue event.

Read the complete Renner case


9. FAQ

What is Tiered Cache?

It’s a multi-layer cache strategy that adds an intermediate level between distributed points of presence and the origin server, consolidating requests and reducing direct calls to the backend.

Is Tiered Cache different from traditional CDN?

Yes. Cache in distributed infrastructure with programmable layers allows granular control over what’s stored, for how long, and with what invalidation criteria. Traditional centralized architecture doesn’t offer this level of control over transactional flows.

Does Selective Caching compromise user data?

No, if configured correctly. Using Advanced Cache Keys ensures different versions of the same resource are stored separately — preventing one session’s data from being delivered to another user.

How to combine Tiered Cache with Micro Caching?

Tiered Cache defines storage layers. Micro Caching defines short TTL for dynamic data. They’re complementary strategies: you can apply Micro Caching within a Tiered Cache architecture for high-variation data.

When to use key-based purge instead of total purge?

Whenever possible. Total purge invalidates the entire application’s cache — including content that hasn’t changed. Key-based purge removes only the fragments affected by the change, keeping the rest of the application accelerated.

How does Tiered Cache help with flash sales?

In flash sales, multiple users access the same resources simultaneously. Tiered Cache consolidates these requests in intermediate layers, drastically reducing pressure on the origin exactly when traffic is at its peak.


Conclusion

Tiered Cache and Selective Caching aren’t isolated optimizations. They’re part of an integrated strategy for origin protection and traffic control for transactional flows at scale.

Tiered Cache solves how many layers to distribute. Selective Caching solves what to cache and with what rule. Together, they increase cache hit ratio, reduce costs, and maintain stable conversion even when traffic spikes.

In high-scale e-commerce, the question isn’t whether you should use layered cache. The question is whether you have enough control over how that cache behaves — and whether it’s programmable enough to keep up with business velocity.


Next steps

Learn about Azion’s Layered Cache solution: https://www.azion.com/en/products/cache/

See how to implement Tiered Cache and Selective Caching in your checkout: Talk to an Azion specialist


stay up to date

Subscribe to our Newsletter

Get the latest product updates, event highlights, and tech industry insights delivered to your inbox.