Tiered Cache: The Free Win for Routing Lag

Your Site is Slow at Night#

Your web app feels fast all day. Then 7 PM hits and every page load starts to drag. You check your VPS: CPU at 2%. You check your logs: database queries finish in milliseconds.

The slowness lives in the route, not your code. If you’re running on a CDN’s free tier with a server in a different region (say, Singapore) while your users are in a place with complex ISP peering (like Indonesia), you’re hitting a routing bottleneck. Before you upgrade your server or move your database, enable one thing: Tiered Cache.

Where the Latency Lives#

Performance issues in a distributed setup usually sit in the “middle mile”:

User <-- ISP Network --> CDN Edge <-- Backbone --> Origin Server
              ^                ^                       ^
         Peak Hour         Anycast                  VPS/SG
         Congestion        Routing

plaintext

At night, ISP networks get crowded. For free-tier CDN users, traffic gets pushed away from expensive local nodes (like Jakarta/CGK) to cheaper international hubs (like Singapore/SIN).

Your user isn’t hitting a local server anymore. They’re contending for bandwidth on an international undersea cable. If the CDN edge doesn’t have your content cached, the request travels even further out to your origin.

How Tiered Cache Fixes This#

Without tiered caching, every CDN edge node talks directly to your origin. If 50 nodes across the globe need your style.css, your origin handles 50 requests.

Tiered Cache adds a hierarchy. A few “Upper Tier” nodes act as a shield between the edge and your origin:

A user hits a local Edge Node.
If the Edge Node doesn’t have the file, it asks an Upper Tier Node: one sitting close to your origin, on the CDN’s private backbone.
If the Upper Tier has it, the user gets it without touching your origin.
If neither has it, only the Upper Tier fetches from your origin; not every edge node independently.

The difference is where the request travels. Edge-to-upper-tier runs over private peering, not public internet. That leg is fast and stable even when ISP networks are congested at night.

Enabling It#

In your CDN dashboard (e.g., Cloudflare):

Go to Caching > Tiered Cache.
Enable Smart Tiered Caching Topology.

The CDN figures out which hub is closest to your server. If your server is in Singapore, it designates the Singapore hub as the Upper Tier. The hop from hub to origin becomes minimal latency.

Verify It’s Working#

After enabling, check the response headers on any cached request:

cf-cache-status: HIT
cf-ray: 8abc123def456789-SIN

plaintext

The airport code at the end of cf-ray is the PoP that served the response. Seeing SIN or KUL instead of a local node doesn’t mean something is wrong: it means the regional hub is doing its job. Your origin is shielded.

Common Gotchas#

Layer	Mistake	Effect
Cache Headers	Setting `no-cache` on static assets	Tiered Cache can’t help if caching is disabled.
Purging	Frequent “Purge Everything”	Forces the CDN to rebuild the cache hierarchy from scratch.
Dynamic Content	Expecting API calls to speed up	Tiered Cache helps files; it doesn’t fix slow DB queries.

Is This Right for You?#

Enable it if your server is in a different country from your primary audience and you’re serving static assets: JS, CSS, images, fonts. If you see colo=SIN (or another non-local PoP) in your CDN analytics during peak hours, that’s the bottleneck this fixes.

Skip it if your app is fully dynamic: every request hits a unique DB query and nothing gets cached. Tiered Cache won’t accelerate those, and neither will any CDN configuration.

If your origin is already under CPU or RAM pressure, fix that first. Tiered Cache reduces load by shielding your origin from repeat requests; it won’t help a server that’s struggling with the requests it does receive.

The middle-mile problem is invisible until you look for it. Once you know where it is, flipping one switch is all it takes.