Redis Caching Patterns

System Design FundamentalsSeniorcachingredissystem-design

The Question

What are the common Redis caching patterns?

What a Strong Answer Covers

• cache-aside = read-driven
• sync vs async distinction
• 3+ patterns.

Senior-Level Answer

Redis caching patterns define how your application coordinates reads and writes between the cache and the source-of-truth database. Choosing the wrong pattern causes stale data, cache stampedes, or write amplification.

**Cache-aside (lazy loading)** is the most common pattern. The application checks Redis first; on a miss it fetches from the DB, writes the result to Redis with a TTL, and returns it. Reads that hit cold keys pay a latency penalty, but the cache only holds data that was actually requested. You own the invalidation logic, which makes it flexible but error-prone.

**Read-through** moves that miss-fill logic into a cache client library or sidecar. The application always talks to the cache; the cache fetches from the DB on misses transparently. This simplifies application code but requires a caching layer that understands your data model. It still suffers the cold-start penalty on first access.

**Write-through** writes to the cache and the database synchronously on every mutation. Reads are always fast because the cache is never stale. The cost is write latency (two writes per mutation) and wasted cache space for data that is written but never read.

**Write-behind (write-back)** writes to Redis immediately and asynchronously flushes to the database. This gives sub-millisecond write latency and can batch DB writes for efficiency. The risk is data loss if Redis crashes before the flush completes — acceptable for metrics or analytics, dangerous for financial records.

Two operational concerns apply to all patterns. **Cache stampede** happens when many requests simultaneously miss the same key (e.g., after TTL expiry). Mitigate with probabilistic early expiration, a mutex lock (Redis SET NX), or request coalescing. **Cache warming** matters at startup — a cold cache under full traffic can overwhelm the database. Pre-warm from a dump or route a fraction of traffic to the cache before full cutover.

In practice most systems combine patterns: cache-aside for reads, write-through for critical writes, and write-behind for high-frequency counters or event streams.

What Separates a 2/3 from a 3/3

Common Mistakes

• Treating cache-aside and read-through as the same pattern — they differ in who owns the miss-fill logic.
• Ignoring TTL strategy: no TTL causes stale data indefinitely; too short causes DB hammering.
• Not addressing cache stampede, which is the most common production failure mode for caching layers.
• Recommending write-behind for financial or transactional data without acknowledging the durability risk.

Follow-Up Questions

• How would you handle cache invalidation when multiple services write to the same data? — Think about event-driven invalidation via pub/sub versus TTL-only strategies and the trade-offs of each.
• What is the thundering herd problem and how does Redis help solve it? — Mention SET NX for distributed locks and probabilistic early expiration.
• How do you warm a cache safely in production without overloading the database? — Traffic shadowing, read-aside with rate limiting, or pre-loading from a recent DB snapshot.
• When would you choose Redis Cluster over a single Redis node, and what changes about your caching patterns? — Hash slots affect key co-location — multi-key operations like MGET require keys in the same slot.

Related Questions

• Vertical vs Horizontal Scaling
• API Versioning
• SLOs vs SLAs
• Availability — Five 9s
• Latency vs Throughput