Multi-Level Caching: L1, L2, CDN in a Single Architecture (2026)

The most surprising thing about multi-level caching is how often it’s treated as a single, monolithic concept, when in reality, each layer operates on fundamentally different principles and timescales.

Imagine a user requesting a product page on an e-commerce site.

User’s Browser (L1 Cache): The browser itself has a cache. If the user has visited this product page before, and the page hasn’t changed, the browser might serve it directly from its local storage. This is the fastest, but also the most ephemeral layer. It’s tied to the user’s session and local machine.

Application Server (L2 Cache): If the browser doesn’t have it, the application server might. This could be an in-memory cache like Redis or Memcached, or even a cache within the application code itself. Here, we’re storing frequently accessed data that’s expensive to compute or fetch from the database. Think of product details, pricing, or user session data. This cache is shared by multiple users hitting the same server instance.

Let’s say we’re using Redis for L2 caching of product data. The application code might look something like this:

import redis
import json

redis_client = redis.Redis(host='localhost', port=6379, db=0)

def get_product_data(product_id):
    cache_key = f"product:{product_id}"
    cached_data = redis_client.get(cache_key)

    if cached_data:
        print(f"Cache HIT for {product_id}")
        return json.loads(cached_data)
    else:
        print(f"Cache MISS for {product_id}")
        # Simulate fetching from a database
        product_data = fetch_from_database(product_id)
        if product_data:
            # Cache for 5 minutes (300 seconds)
            redis_client.setex(cache_key, 300, json.dumps(product_data))
        return product_data

def fetch_from_database(product_id):
    # This would be your actual database query
    print(f"Fetching product {product_id} from DB...")
    return {"id": product_id, "name": f"Product {product_id}", "price": 99.99}

# Example usage:
print(get_product_data(123))
print(get_product_data(123)) # This will be a cache hit

Content Delivery Network (CDN) (Edge Cache): If the L2 cache also misses, the request might go to a CDN. CDNs are distributed networks of servers worldwide. They cache static assets (images, CSS, JavaScript) and sometimes even dynamic content at edge locations geographically close to users. This reduces latency for users far from the origin server and offloads traffic from the origin.

Consider a CDN configuration for static assets. For example, in an Nginx configuration serving a web application:
```
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    root /var/www/html/static;
    expires 30d; # Cache for 30 days
    add_header Cache-Control "public, max-age=2592000"; # 30 days in seconds
    access_log off;
}
```
The expires 30d; and add_header Cache-Control "public, max-age=2592000"; directives tell the browser and any intermediate caches (like CDNs) that these files can be cached for a long time. CDNs will pick up on these headers and cache the content at their edge servers.

The problem this multi-level approach solves is balancing speed, scalability, and cost. L1 is for individual user speed. L2 is for application-level performance and reducing database load. CDN is for global reach, reducing latency for all users, and massive traffic offload. Each layer has a different Time-To-Live (TTL) and invalidation strategy. L1 is often implicit (browser cache based on headers). L2 requires explicit invalidation when data changes. CDN invalidation can be trickier, often involving purging cache entries from edge servers.

The real challenge is cache invalidation. When a product’s price changes, you need to ensure that change propagates through all relevant layers. A common pitfall is updating the database but forgetting to invalidate the L2 cache (e.g., the Redis entry for that product) or the CDN entry. This leads to users seeing stale data, which can be incredibly frustrating. The TTLs are your primary defense against stale data if invalidation is complex or missed. For instance, if your L2 cache TTL is 5 minutes and your CDN TTL is 1 hour, and you miss an invalidation, users might see stale data for up to an hour.

The interaction between these layers is often more nuanced than just a simple hit or miss. For example, a CDN might cache a full HTML page. If that page contains dynamic elements that are supposed to be fresh, you might configure the CDN to cache the HTML page but use JavaScript to fetch dynamic parts from the origin server, bypassing the CDN for those specific, frequently changing data points. This is often called "Edge Side Includes" or similar techniques, allowing parts of a page to be delivered from the edge while other parts are fetched dynamically.

The next problem you’ll likely encounter is managing cache coherency across distributed L2 caches.