Redis Caching Strategies: Cache-Aside, Write-Through, and Cache Invalidation Explained

Cache-Aside (Lazy Loading): The Default Pattern

Cache-aside is the pattern most teams should reach for first. The application checks the cache; on a miss, it reads from the database, writes the result into the cache with a TTL, and returns it. On a hit, it skips the database entirely.

The appeal is that Redis stays a pure performance layer — if it goes down, the application falls back to hitting the database directly (slower, but correct) instead of breaking. The tradeoff is that the first request after a cache miss always pays the full database latency, and data can be stale for up to the TTL window after an underlying update. For read-heavy data that tolerates a few seconds to minutes of staleness — product listings, user profiles, dashboard aggregates — cache-aside with a sensible TTL is almost always the right starting point before reaching for anything more complex.

async function getUser(userId) {
  const cacheKey = `user:${userId}`;
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
  await redis.set(cacheKey, JSON.stringify(user), 'EX', 300); // 5 min TTL
  return user;
}

Related: how missing caching shows up as database waste, PostgreSQL 18's I/O monitoring improvements

Write-Through and Write-Behind: When Staleness Isn't Acceptable

Write-through updates the cache and the database in the same operation — every write goes to Redis first (or in parallel), then to the database, so the cache is never stale after a write completes. This costs extra write latency but eliminates the read-after-write staleness window that cache-aside allows. Write-behind (write-back) goes further: writes land in Redis immediately and are flushed to the database asynchronously in batches, which lowers write latency dramatically but introduces real risk — if Redis crashes before the flush, that data is gone unless it's also persisted (AOF or RDB) or queued somewhere durable.

Write-behind is the right call for high-frequency, loss-tolerant writes like view counters or activity logs; it's the wrong call for anything resembling a financial transaction or order state, where write-through — or no caching on the write path at all — is the safer default.

// Write-through: cache and DB updated together, cache never stale
async function updateUserEmail(userId, email) {
  await db.query('UPDATE users SET email = $1 WHERE id = $2', [email, userId]);
  await redis.set(`user:${userId}`, JSON.stringify({ userId, email }), 'EX', 300);
}

Cache Invalidation: The Actually Hard Part

TTL-based expiration is simple and self-healing — worst case, data is stale for the TTL window, then it corrects itself on the next miss. It's the right default for most data. But some data needs to be correct immediately after a write, not eventually: a user changes their plan tier, and the next request must see the new tier, not the cached one for up to five more minutes.

For that, explicit invalidation on write — deleting or updating the specific cache key the moment the underlying data changes — is required, not optional. The failure mode teams hit here is invalidating the wrong key, or forgetting to invalidate a derived key (a cached list that includes the object you just updated, not just the object's own key). Keep an explicit map of which writes must invalidate which cache keys, including derived and list-level keys, and treat it as part of the data model, not an afterthought bolted onto the update function.

async function updateUserPlan(userId, plan) {
  await db.query('UPDATE users SET plan = $1 WHERE id = $2', [plan, userId]);
  // Invalidate the direct key AND any derived keys that embed this user's data
  await redis.del(`user:${userId}`);
  await redis.del(`user:${userId}:billing-summary`);
}

The Thundering Herd Problem (Cache Stampede)

This is the incident almost every team eventually has. A hot key — say, a homepage feed or a popular product page — expires. In the same instant, hundreds or thousands of concurrent requests all get a cache miss, and all of them hit the database simultaneously to regenerate the same value.

A database that handled the cached load fine gets hit with the full uncached load all at once, and can fall over from a single key's expiration. Two fixes handle this reliably. First, a lock (or 'single-flight' pattern): the first request to miss acquires a short-lived lock and regenerates the value while every other concurrent request either waits briefly or serves the stale value until the lock releases.

Second, probabilistic early expiration: recompute the value slightly before the TTL actually expires, with a random jitter per request, so regeneration is spread out instead of synchronized to the exact expiration millisecond.

async function getWithStampedeProtection(key, fetchFn, ttl = 300) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const lockKey = `lock:${key}`;
  const gotLock = await redis.set(lockKey, '1', 'NX', 'EX', 10);
  if (!gotLock) {
    // Someone else is already regenerating — brief wait, then retry cache
    await new Promise((r) => setTimeout(r, 50));
    return getWithStampedeProtection(key, fetchFn, ttl);
  }

  const value = await fetchFn();
  await redis.set(key, JSON.stringify(value), 'EX', ttl);
  await redis.del(lockKey);
  return value;
}

Related: our database engineering service

Designing Cache Keys That Don't Bite You Later

Cache key design looks trivial until a schema change or a feature flag makes half your cached data structurally wrong in a way nothing detects. Version your keys — user:v2:123 instead of user:123 — so a shape change to the cached payload can't silently return old-shaped data to code expecting the new shape; bump the version and old keys simply expire unread. Namespace keys by tenant in multi-tenant systems (tenant:42:user:123) to make it structurally impossible for one tenant's cached data to leak into another's request.

, while user:123:profile tells them everything they need to check it manually with redis-cli.

When Redis Caching Is the Wrong Fix

Caching is frequently used to paper over a query that should be fixed instead. If a dashboard is slow because of an unindexed full table scan, caching the result hides the symptom without addressing the fact that the underlying query will time out the moment cache is cold, memory pressure evicts the key, or a new code path queries the same data without going through the cache. Fix the query first; cache what's still expensive after that.

Caching is also the wrong call when consistency requirements are genuinely strict — inventory counts during checkout, account balances, anything where a stale read causes a real business error rather than a cosmetic delay. In those cases, the correct fix is usually a faster, correctly indexed read from the source of truth, not a cache with a short enough TTL to feel safe.

Related: how to debug slow SQL queries