Caching Strategies: Redis, CDN, and Multi-Level Caches

A database query that takes 50ms is slow. An in-memory Redis lookup that takes 0.1ms is fast. When 1,000 users request the same product page simultaneously, serving it from cache costs one database roundtrip instead of a thousand. That's the core trade-off: spend a little memory to save a lot of computation.

Cache hits improve latency and throughput. They also protect databases during traffic spikes — the cache absorbs demand that would otherwise queue up, time out, and cascade into full outages. Understanding which data benefits from caching is the first step: read-heavy, change-infrequently data (product catalogs, user profiles, configuration) is a perfect fit. Write-heavy, highly-personalized, or financial data (account balances, order state) needs careful handling.

Cache-aside is the most widely used pattern. The application checks the cache first. On a miss, it fetches from the database, writes the result to cache, then returns it. The cache is populated lazily — only the data that is actually requested gets cached.

This pattern works well because the cache only holds data that users actually need. It's resilient: if the cache goes down, the application falls back to the database without crashing. The downside is that the first request for any key is always slow (a cache miss), and if you have many simultaneous first requests for the same key (a thundering herd), you can hammer the database.

Read-through differs from cache-aside in who owns the miss logic. The cache itself fetches from the database when a key is absent, not the application. The application always talks to the cache layer and never directly to the database. Libraries like Amazon ElastiCache or a Hibernate second-level cache implement this pattern.

Write-through keeps cache and database always in sync: writes go to the cache first, which synchronously writes through to the database before confirming to the caller. Every write is slower (two writes instead of one), but every read is guaranteed to be fresh. This is useful when you can't tolerate stale reads — user account data, inventory counts, or permissions.

Redis isn't just a key-value store — its native data structures let you cache complex access patterns efficiently without deserializing entire objects.

Strings store serialized JSON for simple object caching. Hashes store individual fields of a record, so you can update one field without fetching and rewriting the full object. Sorted Sets let you maintain a leaderboard or a time-ordered feed in cache. Sets support fast membership checks — 'is user X in the beta group?' answered in O(1). Lists power queues and recent-activity feeds. Choosing the right structure directly reduces memory usage and eliminates unnecessary round trips.

A CDN (Content Delivery Network) caches responses at edge nodes physically close to users. A user in London hitting a CDN node in London receives a cached response in ~5ms; the same request without CDN might travel to a US origin server and back in 180ms. CDNs are the outermost caching layer — they sit in front of everything.

For static assets (JS, CSS, images), CDN caching is straightforward: set long Cache-Control max-age headers and bust them with content hashes in filenames. For API responses, CDN caching is trickier: you must set Surrogate-Control or Cache-Control headers on the response, vary correctly on headers that affect content (Accept-Language, Accept-Encoding), and purge keys when content changes.

Phil Karlton famously said there are only two hard problems in computer science: cache invalidation and naming things. The difficulty is that cached data has two owners — the cache and the source of truth — and keeping them in sync without serving stale data or over-evicting is genuinely hard.

The three main strategies are TTL-based expiry (simplest, always eventually consistent), event-driven invalidation (purge specific keys when the underlying data changes — complex but precise), and versioning (never invalidate; instead use new keys when data changes — cache:user:v2:{id}).

Production systems rarely use a single cache. A typical architecture has three layers: an in-process cache (memory inside the application process), a distributed cache (Redis shared across all instances), and a CDN or reverse proxy cache (Nginx, Varnish, or a cloud CDN).

In-process cache (e.g. a ConcurrentDictionary in .NET or an LRU Map in Node) is the fastest — nanoseconds — but is per-instance and loses state on restart. Distributed cache (Redis) is milliseconds and shared across instances. CDN is the outermost layer and absorbs the most traffic. Requests move outward when they miss: process → Redis → origin database.