Where to Cache: Client, CDN, Server, Database

The question of where to cache is as important as whether to cache. Data can be cached at multiple points along the request path, from the user's browser to the database's internal buffer pool. Each caching layer offers different characteristics: latency (how fast is a cache hit), capacity (how much data can be stored), scope (who shares the cache), invalidation (how stale data is removed), and complexity (how hard is it to implement and operate). Placing the cache at the wrong layer can be ineffective or counterproductive -- caching at the application server when the bottleneck is the database query cache, or caching at the CDN when the data is user-specific.

Browser caching is the closest cache to the user, with zero network latency on a hit. HTTP cache-control headers (max-age, no-cache, must-revalidate, stale-while-revalidate) give the server fine-grained control over what browsers cache and for how long. Service workers extend browser caching with programmable logic: caching API responses, implementing offline-first strategies, and pre-caching resources during idle time. Conditional requests using ETags and If-None-Match allow the browser to validate cached content without re-downloading it -- the server returns 304 Not Modified if the content has not changed, saving bandwidth. Browser caching is extremely effective for static assets (CSS, JS, images) and semi-static content (user preferences, configuration), but it is per-user and cannot be centrally invalidated without deploying new URLs (cache-busting via content hashes in filenames).

CDN caching sits between users and the origin server, serving cached content from geographically distributed edge nodes. CDNs excel at caching static assets and public API responses that are identical for all users. The Vary header allows CDNs to cache different versions based on request headers (Accept-Encoding, Accept-Language), enabling efficient caching of content that varies by client capability. CDN caching is powerful but invalidation is slow -- cache purge requests take seconds to minutes to propagate across all edge nodes. Application-level caching using Redis or Memcached stores computed results, aggregated data, and expensive query results close to the application logic. This is the most flexible caching layer because the application controls what is cached, how it is keyed, and when it is invalidated. Redis caching is appropriate for session state, rate limiting counters, feature flags, precomputed feeds, and any data that is expensive to compute from the database.

Database-level caching includes the buffer pool (InnoDB, PostgreSQL shared_buffers), which automatically caches frequently accessed data pages in memory, and the query cache (MySQL, now deprecated). The buffer pool is transparent to the application -- it automatically caches hot data pages and evicts cold ones using LRU. The MySQL query cache, which cached exact SQL query results, was deprecated in MySQL 8.0 because its invalidation overhead (invalidating all cached results for a table on any write to that table) made it counterproductive for write-heavy workloads. PostgreSQL's shared_buffers and the OS page cache together form an effective transparent caching layer that requires no application changes. The decision framework for where to cache follows a principle: cache data as close to the consumer as possible (browser > CDN > application > database), using the appropriate invalidation strategy for each layer.

Think of the request path like grocery shopping. Your pantry at home (browser cache) has ingredients you use every day -- instant access, no trip needed. The local convenience store (CDN) has common items within walking distance -- quick access for popular products. The full grocery store across town (application cache/Redis) has everything in stock -- wider selection but requires a drive. The wholesale warehouse (database) has bulk supplies -- largest selection but farthest away. You stock your pantry with daily essentials, the convenience store carries neighborhood favorites, and you only drive to the grocery store or warehouse for items not available closer to home.