Tiered Caching (L1/L2/CDN)

Tiered caching, also called multi-layer or hierarchical caching, arranges multiple cache layers in a hierarchy where each tier offers different trade-offs between latency, capacity, and scope. The closest tier (L1, in-process) provides the fastest access but has the smallest capacity and is local to a single application instance. The next tier (L2, distributed) is shared across all instances and offers much larger capacity at slightly higher latency. The outermost tier (L3, CDN) provides global reach with massive capacity but is limited to content that can be served without application logic.

L1 caches run in the application process itself -- libraries like Caffeine (JVM), Guava Cache (JVM), or simple in-memory maps. Access latency is measured in microseconds (0.1-1 us) because there is no network round trip. However, L1 caches are limited by the application's heap size (typically 100MB-2GB) and are not shared across instances. Each application server has its own L1 cache, which means the same data may be cached N times across N servers, and cache coherence is harder to maintain. L2 caches are distributed caching systems like Redis or Memcached that sit on dedicated servers accessible over the network. Access latency is 0.5-2ms (network round trip), but capacity can be terabytes across a cluster. L2 caches are shared across all application instances, providing a single source of cached truth.

The request flow in a tiered architecture is straightforward: check L1 first, then L2, then L3 (if applicable), and finally the origin (database or API). When data is found at any tier, it is returned to the caller and optionally promoted to higher tiers. For example, an L2 hit might populate the L1 cache so subsequent requests from the same instance get microsecond access. Cache coherence across tiers is the primary challenge. When data changes, all tiers must be invalidated or updated. Common approaches include pub/sub invalidation (Redis pub/sub or Kafka events notify all L1 caches to evict a key), TTL cascading (L1 uses shorter TTLs than L2, which uses shorter TTLs than L3), and write-through at each tier.

Not every system needs tiered caching. A single Redis cache (L2 only) is sufficient for most applications. Add L1 when network round trips to Redis dominate your latency budget and you can tolerate brief inconsistency between instances. Add CDN (L3) when you serve content globally and the origin cannot handle the aggregate request volume from all edge locations. Each tier adds operational complexity: L1 requires coherence management, L2 requires cluster operations, and CDN requires cache purge workflows. Start with one tier and add layers only when measured performance data justifies the complexity.

Think of caching tiers like office supplies. Your desk drawer (L1) has a few pens and sticky notes -- instant access but limited space. The supply closet down the hall (L2) has more of everything -- a quick walk to get what you need. The warehouse across town (L3/CDN) has every supply the company stocks -- takes a delivery truck to get things, but capacity is enormous. The factory (origin/database) can make anything but takes the longest. You check your desk first, then the closet, then order from the warehouse, and only call the factory as a last resort. Most days, your desk and the closet have everything you need.