Question 1

Cache key missing the tenant (Redis caching)

Accepted Answer

Users occasionally see another organisation's data. Never reproducible locally. One key serves every tenant, so whichever request populates it first shares its data with everyone until expiry. Single-tenant development and staging never surface it — it needs concurrent multi-tenant traffic to appear. Fix: // Every variable that changes the value belongs in the key.
const key = `dashboard:summary:v2:${orgId}:${period}`;

Question 2

Thundering herd on expiry (Redis caching)

Accepted Answer

A latency and CPU spike at a fixed interval, exactly matching the TTL. When the key expires, every in-flight request misses simultaneously and all of them run the expensive query against the database at once. The cache amplifies the spike instead of absorbing it. Fix: let data = await redis.get(key);
if (!data) {
  // First caller wins the lock and refreshes; the rest wait briefly and re-read.
  const gotLock = await redis.set(`${key}:lock`, "1", "EX", 10, "NX");
  if (gotLock) {
    data = await expensiveQuery();
    // Jitter the TTL so keys don't re-expire in lockstep.
    await redis.setex(key, 300 + Math.floor(Math.random() * 60), JSON.stringify(data));
    await redis.del(`${key}:lock`);
  } else {
    await new Promise((r) => setTimeout(r, 50));
    data = await redis.get(key);
  }
}

Question 3

KEYS against a production instance (Redis caching)

Accepted Answer

Periodic full-server stalls; every client times out at once. Redis is single-threaded and `KEYS` walks the entire keyspace before returning. On a few million keys that blocks every other command for seconds — the whole server, not just the caller. Fix: // SCAN is incremental and cooperative.
let cursor = "0";
do {
  const [next, batch] = await redis.scan(cursor, "MATCH", "session:*", "COUNT", 100);
  cursor = next;
  if (batch.length) await redis.unlink(...batch);   // UNLINK frees asynchronously
} while (cursor !== "0");

Question 4

Cached entries with no TTL (Redis caching)

Accepted Answer

Memory climbs steadily until Redis starts evicting keys you needed. A `SET` with no expiry keeps the key forever. Memory grows with total users ever seen rather than active users, and once `maxmemory` is reached the eviction policy — not you — decides what to drop. Fix: await redis.setex(`user:${id}:profile`, 3600, JSON.stringify(profile));
// And set an explicit policy so eviction is a decision, not a surprise:
//   maxmemory-policy allkeys-lru

Performance audits for Redis caching

Check a file now — free

What we find most often in Redis caching

1. Cache key missing the tenant

2. Thundering herd on expiry

3. KEYS against a production instance

4. Cached entries with no TTL

An automated pass reads one file. An audit reads the system.

Related audits