Most traditional CDN users stop at single-tier edge caching and accept a modest cache hit ratio as "normal." However, It's NOT - it's a hard architectural ceiling. ESA's multi-level cache (Tiered Cache) adds Regional, Smart, and Cache Reserve layers that substantially lift hit ratios and offload your origin. No code changes. No DNS changes. Just enable the right tiers.
Alibaba Cloud ESA (Edge Security Acceleration) provides a multi-level caching architecture that goes beyond traditional single-tier CDN caching. Instead of one shot at caching content at the edge, ESA gives every request multiple chances to be served from cache — across edge, regional, and origin-adjacent tiers, plus a persistent cold-storage layer — before it ever touches your origin server.
The result: a cache hit ratio well beyond the ceiling that single-tier edge caching imposes, and far fewer requests reaching your origin.
New to ESA? ESA is Alibaba Cloud's edge security and acceleration platform, combining CDN, WAF, DDoS protection, and edge computing in one product. In the ESA console this feature lives under Caching > Tiered Cache.
This article explains the architecture, walks through where it helps most, and shows how to set it up.
Traditional CDN caching works in one layer: content gets cached at the edge POP closest to the user. If it's not there, the request goes all the way back to origin.
This works well for hot content: the small share of your assets that generates most of your traffic. But it fails for everything else:
| Problem | Impact |
|---|---|
| Limited edge storage | Edge POPs have limited capacity. Cold content gets evicted aggressively. |
| No second chance | Once evicted from an edge POP, the next request goes to origin — even if the same content is still cached in another region. |
| Geographic fragmentation | A file cached in one region doesn't help a user in another. Each edge POP operates independently. |
| Cold content penalty | Long-tail content (old blog posts, niche product images, archived docs) never stays cached long enough. |
| The Pareto trap | Most traffic concentrates on a small slice of content. That hot slice caches beautifully; the long tail generates nearly all cache misses. |
The result is predictable: most users enable CDN, watch their cache hit ratio climb to a modest level, and stop there. They scale origin servers and add bandwidth — working around the problem instead of solving it.
ESA's multi-level cache solves this.
ESA's multi-level cache isn't a single fixed pipeline — it's a set of tier configurations you choose between, depending on your traffic pattern and plan. Each configuration adds an intermediate caching layer between the edge and your origin:
| Configuration | Tiers | What it does | Best for |
|---|---|---|---|
| Edge Tiered Cache | 1 | Edge nodes only (3,200+ globally), nearest to each user | Hot content, baseline caching |
| Edge + Regional | 2 | Regional nodes (deployed by region/province, near the edge) consolidate traffic from edge nodes in the same area before fetching from origin | Improving origin-fetch performance across a multi-region audience |
| Edge + Smart | 2 | Smart (intelligent) nodes sit near your origin, fewer of them, consolidating origin-fetch traffic | Maximizing hit ratio when you want to converge origin load |
| All Cache Tiers | 3 | Edge + Regional + Smart combined (Enterprise only) | High-traffic scenarios needing maximum origin convergence |
2 things to note:
Regional and Smart are alternatives, not sequential layers. At the two-tier level you pick the topology that fits: Regional (nodes near the edge, organized by region) or Smart (nodes near the origin). You don't stack one on top of the other. Only the Enterprise All Cache Tiers mode combines edge, regional, and smart into a single three-tier path.
Smart Tier is especially powerful for origins in mainland China. If your origin is in Hangzhou, Smart Tier uses a nearby Shanghai-area POP as an intermediate cache — so an edge POP in Europe hits a Smart Tier POP in China instead of making a transcontinental request to your origin.
The full Enterprise path (All Cache Tiers + Cache Reserve) looks like this:
User Request
│
▼
┌──────────────────────────────────────┐
│ Edge Tiered Cache │ 3,200+ nodes · nearest to user
│ (Tokyo, Mumbai, Frankfurt, ...) │ single-tier baseline
└──────────────┬───────────────────────┘
│ miss
▼
┌──────────────────────────────────────┐
│ Regional Tiered Cache │ near edge · by region/province
│ consolidates regional traffic │ (Pro+ — OR Smart, pick one)
└──────────────┬───────────────────────┘
│ miss
▼
┌──────────────────────────────────────┐
│ Smart Tiered Cache │ near origin · fewer nodes
│ converges origin fetch │ (Pro+ — OR Regional, pick one)
└──────────────┬───────────────────────┘
│ miss
▼
┌──────────────────────────────────────┐
│ Cache Reserve │ persistent cold-storage POP
│ (subscription instance) │ no eviction · cold long-tail
└──────────────┬───────────────────────┘
│ miss
▼
Origin ServerReading the diagram: Pro and Premium plans choose either Regional or Smart as their second tier. The Enterprise All Cache Tiers mode is what wires edge + regional + smart into one three-tier path; Cache Reserve then sits on top as a persistent layer for cold content.
Cache Reserve is a separate, persistent caching layer for content that should be cached indefinitely — the long tail that regular tiers evict. ESA routes requests through a top-level Cache Reserve POP that holds less-popular files so they aren't pushed out by hot content.
Unlike edge/regional tiers that use LRU-style eviction, Cache Reserve keeps content until you purge it or your retention expires. It targets cold traffic; for hot traffic you typically add a cache rule to bypass Cache Reserve and save storage cost.
Important: Cache Reserve is subscription-based. You purchase a Cache Reserve instance (choosing a region and storage capacity) through your sales team, then associate websites with it. Each instance supports up to 20 websites, and it works best when the tiered cache mode is set to All Cache Tiers (other modes work but yield lower hit ratios and higher storage usage).
Note: These are representative scenarios illustrating where each tier adds value. They describe the pattern, not measured benchmarks.
Game patches are large and short-lived at the edge — new patches evict old ones quickly, but plenty of users haven't updated yet. A regional tier holds patches far longer than any single edge POP, so users across the region who haven't updated still pull the patch from cache instead of the origin.
The benefit: far fewer origin fetches for large assets, faster patch downloads for laggards.
Breaking news is cached aggressively at the edge, but yesterday's articles get evicted as new stories arrive. A regional tier keeps recent articles warm much longer, and Cache Reserve holds the deep archive permanently.
The benefit: archive reads stay off the origin; you can run fewer origin servers.
For an API serving many regions, most reads are cacheable but spread thin across edge POPs, so each POP misses on its own. Smart Tier converges origin-fetch traffic through a node near the origin, so repeated misses consolidate into far fewer origin requests.
The benefit: origin load converges; lower origin infrastructure and bandwidth cost.
The vast majority of product SKUs receive no views for long stretches — a classic long tail. Edge tiers evict them, so every rare view misses cache and hits the origin. Cache Reserve caches the entire catalog persistently.
The benefit: the whole long tail stays cached; origin load drops sharply.
Articles sit unviewed for weeks, then a social-media share triggers a traffic spike. Without a persistent layer, those articles always miss cache and hit the database. Cache Reserve keeps every article cached, so spikes are absorbed.
The benefit: database load stays flat even during viral spikes.
Each layer catches the requests the one before it missed:
Stack them, and the share of requests that reach your origin shrinks at every step — often to a small fraction of total traffic. Your exact gain depends on your traffic shape (how much hot vs. cold content you serve), but the direction is consistent: more tiers, fewer origin requests.
The cost impact follows directly. Fewer origin requests means lower origin compute, storage, and bandwidth spend — and less need to over-provision origin capacity for traffic that a cache could have absorbed.
ESA Console → Websites → click your site → Caching > Tiered Cache → Configure.
| Option | Plan | Best for |
|---|---|---|
| Edge Tiered Cache | Entrance / Pro / Premium / Enterprise | Default single-layer caching |
| Edge + Regional | Pro / Premium / Enterprise | Multi-region audience, better origin-fetch performance |
| Edge + Smart | Pro / Premium / Enterprise | Origin in a specific geography (esp. mainland China), maximize hit ratio |
| All Cache Tiers | Enterprise | Maximum origin convergence (contact us to request) |
Pick one configuration and confirm. No DNS changes, no code changes, no origin reconfiguration. Settings take effect in about 3-5 minutes.
Heads-up: When multi-level cache is set to Edge Tiered Cache only, the Cache Warm-up feature is unavailable. If you rely on warm-up, use a two-tier or higher configuration.
Cache Reserve is a subscription instance, not a simple toggle:
/images/products/*, /docs/*; extensions like .jpg, .png, .pdf; or use Cache Rules for complex logic) and set retention (indefinite or time-based).Notes: each instance supports up to 20 websites; for best results set the tiered cache mode to All Cache Tiers; for hot traffic, add a cache rule to bypass Cache Reserve and reduce storage cost.
Check the X-Cache response header to confirm whether content was served from cache:
| Header | Meaning |
|---|---|
HIT |
Served from cache |
MISS |
Fetched from origin |
Give it a day or two, then check the cache hit ratio (with per-tier breakdown where available) in ESA analytics.
Even with Tiered Cache enabled, these misconfigurations will reduce effectiveness:
| Mistake | Why it hurts | Fix |
|---|---|---|
| Short TTLs on static content | A few minutes of max-age on product images means they expire constantly, defeating the regional/smart tier entirely |
Set long TTLs (days/weeks) for static assets |
| Overly aggressive cache purge | Purging everything after a deploy wipes all tiers → thundering herd to origin | Purge selectively by URL pattern or tag |
| Ignoring Vary header |
Vary: User-Agent creates a separate cache entry per user agent, fragmenting cache |
Remove unnecessary Vary headers, or normalize with Transform Rules |
| Cache key missing headers |
/api/users returns per-user data but the cache key omits the Authorization header |
Include relevant headers in the cache key via Cache Rules |
| Expecting warm-up on Edge-only mode | Cache Warm-up is unavailable when multi-level cache is set to Edge Tiered Cache | Use a two-tier (Regional or Smart) or higher config if you need warm-up |
| Sending hot traffic through Cache Reserve | Cache Reserve is for cold content; caching hot content there wastes paid storage | Add a cache rule to bypass Cache Reserve for hot paths |
| Skipping Cache Reserve for long-tail | Regional/Smart tiers still evict eventually. Without Reserve, old product images still miss | Enable Cache Reserve for catalog/archive paths |
| Scenario | Recommended setup |
|---|---|
| Small site, mostly hot content | Edge Tiered Cache |
| E-commerce, moderate catalog | Edge + Regional |
| Origin in mainland China, global audience | Edge + Smart |
| Large media platform, long-tail content | All Cache Tiers + Cache Reserve |
| Software company, frequent releases | Edge + Smart + Cache Reserve |
| Gaming, massive asset library | All Cache Tiers + Cache Reserve |
Rule of thumb:
Does Tiered Cache add latency?
No, it usually reduces it. The edge POP still serves the user directly; the only difference is where the edge POP fetches content from on a miss. Smart Tier often lowers latency because its nodes sit closer to your origin than the edge POP would.
Cache Reserve vs. OSS, what's the difference?
OSS is your origin storage — you upload and manage files there. Cache Reserve is a caching layer ESA manages automatically. Think of OSS as your warehouse; Cache Reserve as a shelf in the delivery truck that never gets cleared out.
Do I need Cache Rules to use Tiered Cache?
No. Tiered Cache works automatically from your existing cache settings. Cache Rules just add per-path control — e.g. "cache this path at the regional tier for a long window, this other path at edge for a short one."
Can I use Cache Reserve without Tiered Cache?
Cache Reserve works best with the tiered cache mode set to All Cache Tiers. Other modes work but yield lower hit ratios and higher storage usage.
What plans include each tier?
| Feature | Entrance | Pro | Premium | Enterprise |
|---|---|---|---|---|
| Edge Tiered Cache | ✅ | ✅ | ✅ | ✅ |
| Edge + Regional | ❌ | ✅ | ✅ | ✅ |
| Edge + Smart | ❌ | ✅ | ✅ | ✅ |
| All Cache Tiers | ❌ | ❌ | ❌ | ✅ |
| Cache Reserve | ❌ | ❌ | ❌ | ✅ |
ESA Unlocked: Smart Routing - Making Dynamic Content as Fast as Static
ESA Unlocked: Origin Protection - Stop Attackers from Bypassing Your CDN
8 posts | 1 followers
FollowBryan, Zhang - June 23, 2026
Bryan, Zhang - September 7, 2026
Bryan, Zhang - October 5, 2026
Bryan, Zhang - June 17, 2026
Bryan, Zhang - May 28, 2026
Kidd Ip - September 15, 2025
8 posts | 1 followers
Follow
Edge Security Acceleration (Original DCDN)
Edge Security Acceleration (ESA) provides capabilities for edge acceleration, edge security, and edge computing. ESA adopts an easy-to-use interactive design and accelerates and protects websites, applications, and APIs to improve the performance and experience of access to web applications.
Learn More
CDN(Alibaba Cloud CDN)
A scalable and high-performance content delivery service for accelerated distribution of content to users across the globe
Learn More
Content Delivery Solution
Save egress traffic cost. Eliminate all complexity in managing storage cost.
Learn More
Edge Node Service
An all-in-one service that provides elastic, stable, and widely distributed computing, network, and storage resources to help you deploy businesses on the edge nodes of Internet Service Providers (ISPs).
Learn MoreMore Posts by Bryan, Zhang