What is Tiered Caching? | Multi-Layer Cache Architecture

Tiered Caching adds intermediate cache layers between distributed edge nodes and the origin server. This multi-layer architecture consolidates requests, increases cache hit ratio, and reduces direct calls to the origin during traffic spikes.

What is Tiered Caching?

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

How Tiered Cache works

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.

Request arrives at point of presence
      ↓
Check local cache (L1)
      ↓
Cache HIT → Immediate response
Cache MISS → Query intermediate layer (L2)
      ↓
L2 HIT → Response + populate L1
L2 MISS → Query origin → Populate L2 + L1 → Response

Benefits of Tiered Caching

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.

Tiered Cache vs Selective Caching

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

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

Both strategies are complementary — not mutually exclusive.

What can and cannot be cached with Tiered Caching

Programmable cache with Tiered Caching

Tiered Cache becomes even more powerful when part of a programmable cache 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 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 };
}

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:

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

→ Read the complete Renner case

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.

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 is part of an integrated strategy for origin protection and traffic control for transactional flows at scale.

It solves how many layers to distribute cache across. Combined with Selective Caching, it increases cache hit ratio, reduces costs, and maintains stable conversion even when traffic spikes.

Next steps

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

See how to implement Tiered Caching in your architecture: Talk to an Azion specialist