Redis Caching Patterns — Cache-Aside, Write Strategies, Eviction, and Stampede

What a Cache Really Is

Why Caching Is Needed — The Read/Write Problem

A database is great at keeping data safe. It is not great at answering the same read a million times a second. Every read means a disk touch, a query plan, maybe a row lock. Under load, the database becomes the slow point for the whole app.

Without a cache, every read lands on the database. Popular data means the same query runs thousands of times a second and the database heats up.

Cache-Aside (Lazy Loading), Step by Step

Cache-aside is the most common pattern. The app manages the cache itself. It looks in Redis first; on a miss it reads the database and copies the result into Redis. The cache fills "lazily", only with data that is actually asked for.

A hit returns straight from Redis. A miss reads the database, then fills Redis so the next read is fast.

# cache-aside read, in pseudo-code
function get_user(id):
    val = GET user:{id}              # 1. look in Redis
    if val is nil:                     # miss
        val = db.query("SELECT ... WHERE id = ?", id)   # 2. read DB
        SET user:{id} val EX 600     # 3. fill cache, 10 min TTL
    return val

Write-Through and Write-Behind

Cache-aside fills the cache on reads. But what about writes? Two patterns keep the cache fresh when data changes: write-through and write-behind.

Write-through saves to cache and database together, then returns. Write-behind saves to the cache now and to the database a moment later, in the background.

Cache Invalidation — The Hard Part

There is an old joke: the two hardest things in computing are naming things, cache invalidation, and off-by-one errors. Invalidation is hard because a cached copy can quietly go stale after the database changes. Here are the three safe ways to handle it.

# when the user is updated, invalidate the cache
db.query("UPDATE users SET city = ? WHERE id = ?", city, id)
DEL user:{id}                 # drop the stale copy; next read rebuilds it

# safest default: short TTL as a backstop, even if you also DEL
SET user:{id} val EX 300

Eviction Policies and maxmemory

Memory is limited. You set maxmemory, and when Redis is full it must remove something to store new data. The maxmemory-policy decides which key to drop. Picking the right policy keeps the useful data and evicts the rest.

When memory is full, a new key needs room. The policy chooses a victim — here the least-recently-used key — and evicts it to make space.

# set a memory limit and a policy
CONFIG SET maxmemory 2gb
CONFIG SET maxmemory-policy allkeys-lru

# check what is set
CONFIG GET maxmemory-policy

Cache Stampede, Thundering Herd, and Hot Keys

A popular key expires. In the same instant, thousands of requests look for it, all miss, and all rush to the database at once. This is a cache stampede (or thundering herd), and it can knock the database over — the very thing the cache was meant to prevent.

The moment a hot key expires, every waiting request misses together and stampedes to the database.

How to prevent it

# single-flight: only the first request rebuilds; others back off
val = GET product:9
if val is nil:
    got = SET lock:product:9 1 NX EX 5   # try to grab the rebuild lock
    if got == "OK":
        val = db.query("SELECT ... WHERE id = 9")   # only one query hits the DB
        SET product:9 val EX (600 + rand(0,60))     # jittered TTL
        DEL lock:product:9
    else:
        sleep(50 ms); val = GET product:9        # wait for the rebuild, then read

Golden Rules