Phase 6Intermediate7 of 17 in Redis

Caching Patterns

Cache-aside, read-through, write-through and write-behind; invalidation races; penetration, stampede and avalanche; warming and multi-level caches.

Caching is the most common reason teams adopt Redis and the most common source of subtle bugs: stale values that come back after an update, a database flattened by a single expired key, attackers bypassing the cache, and caches that go cold at the worst moment.

This phase builds a correct cache step by step, then breaks it in every classic way and fixes each failure with the pattern interviewers expect you to name.

0/7 · 0%

7 topics ~67 min 15 code blocks & diagrams

Start with the first topic

6.1

Cache-Aside: The Default Pattern

In cache-aside (lazy loading), the application checks Redis first, and on a miss reads the database and stores the result with a TTL. Writes go to the database and then delete the cached entry. It's simple, resilient to cache failure, and the default choice, as long as you handle its races.

10 min 1 diagram 1 code practice

6.2

Read-Through, Write-Through, and Write-Behind

Read-through moves loading logic into the cache layer; write-through writes the cache and database together for fresher reads; write-behind writes the cache first and flushes to the database asynchronously for speed, at the risk of losing writes. Each moves responsibility and risk to a different place.

10 min 1 diagram 1 code practice

6.3

Cache Invalidation and Consistency Races

Stale values reappear when a slow reader writes an old database value into the cache after a writer already invalidated it. The fixes, in increasing strength: delete after commit, short TTLs, delayed double delete, versioned or compare-and-set cache writes, and change-data-capture invalidation.

10 min 2 diagrams 1 code practice

6.4

Cache Penetration: Requests for Things That Don't Exist

Cache penetration happens when requests ask for keys that exist neither in the cache nor in the database, so every request reaches the database. Defend with input validation, negative caching, Bloom filters, and rate limiting.

8 min 1 code practice

6.5

Cache Stampede: When a Hot Key Expires

When a very popular key expires (or is evicted), thousands of concurrent requests miss at once and all hit the database for the same value. Prevent it with request coalescing, a rebuild lock, probabilistic early refresh, stale-while-revalidate, or background refresh.

11 min 1 diagram 2 code practice

6.6

Cache Avalanche and Cache Warming

A cache avalanche is many keys expiring or disappearing at the same time (synchronized TTLs, a Redis restart, a cold deployment), sending a flood of misses to the database. Prevent it with TTL jitter, staggered expiry, warming, multi-level caches and database protection.

9 min 1 diagram 1 code practice

6.7

Multi-Level Caching and Hit Ratio

Layering an in-process L1 cache in front of Redis (L2) in front of the database (L3) cuts latency and removes hot-key load, at the cost of more places for data to go stale. Measure hit ratio per layer, but optimise for user latency and database load, not the ratio itself.