Cache Tier Strategies

title: "Cache Tier Strategies — Multi-Layer Caching for Maximum Performance" description: "Cache tier strategies combine browser, CDN, reverse proxy, and application caches in a multi-layer hierarchy to maximize hit ratios and minimize latency." date: 2026-06-28 lastmod: 2026-06-28 weight: 23 tags: [apis, caching] }

Multi-tier caching combines browser cache, CDN edge cache, reverse proxy cache, and application cache in a hierarchy, with each layer catching requests the previous one missed.

What You'll Learn

• Cache tier hierarchy
• How each layer interacts
• TTL coordination across tiers

Why It Matters

A single cache layer misses often. Four layers in sequence achieve 99%+ effective hit rates, serving most requests without touching the database.

Multi-Tier Architecture

flowchart TD
    C[Client Browser] -->|Layer 1: Browser Cache| B
    B -->|Miss| CDN[Layer 2: CDN Edge]
    CDN -->|Miss| RP[Layer 3: Reverse Proxy]
    RP -->|Miss| AC[Layer 4: App Cache - Redis]
    AC -->|Miss| DB[(Database)]
    DB --> AC
    AC --> RP
    RP --> CDN
    CDN --> B
    B --> C

Code Examples

# Tier 4: Application cache (Redis)
@app.route('/api/products')
def get_products():
    # Check Redis first
    cached = redis.get('products')
    if cached:
        response = jsonify(json.loads(cached))
        response.headers['X-Cache'] = 'app-hit'
        return response

    # Fetch from database
    products = db.get_products()
    redis.setex('products', 300, json.dumps(products))

    response = jsonify(products)
    response.headers['X-Cache'] = 'miss'
    return response

# Tier 3: Nginx reverse proxy cache
proxy_cache_path /var/cache/nginx levels=1:2
                 keys_zone=api_cache:10m
                 max_size=1g
                 inactive=60m;

server {
    location /api/ {
        proxy_cache api_cache;
        proxy_cache_valid 200 5m;
        proxy_cache_key "$host$request_uri";
        proxy_pass http://app_server;

        # Add cache status header
        add_header X-Cache-Status $upstream_cache_status;
    }
}

// Tier 2: CDN (CloudFront) configuration
// Origin response headers control CDN caching
app.get('/api/products', (req, res) => {
  res.set({
    'Cache-Control': 'public, max-age=60, s-maxage=300',
    'CDN-Cache-Control': 'max-age=300'
  });
  res.json(products);
});

// Tier 1: Browser cache controlled by max-age
// Client receives: Cache-Control: public, max-age=60
// Browser caches for 60 seconds

Common Mistakes

1. Uncoordinated TTLs

Different tiers with conflicting TTLs cause inconsistent behavior.

2. Missing Cache Status Headers

Without X-Cache headers, debugging which tier served the response is hard.

3. Same TTL at All Tiers

Lower tiers (browser) should have shorter TTLs than upper tiers (Redis).

4. No Graceful Degradation

If Redis is down, the reverse proxy cache should still serve stale data.

5. Over-Invalidation

Invalidating all tiers simultaneously causes cascading cache misses.

Practice Questions

1. What are the four cache tiers from client to database?
2. How should TTLs differ between tiers?
3. Why add X-Cache-Status headers?
4. What happens when Redis cache is down?
5. How do you coordinate invalidation across tiers?

Answers:

1. Browser, CDN, Reverse Proxy, App Cache (Redis).
2. Lower tiers (browser) should have shorter TTLs than upper tiers.
3. To identify which tier served the response for debugging.
4. Reverse proxy and CDN should still serve cached data.
5. Invalidate from top-down: Redis first, then proxy, then CDN.

Challenge: Implement a four-tier caching system for your API. Add X-Cache headers for each tier and test the cascading miss behavior.

FAQ