Caching Patterns Interview Questions

Cache-aside means the app reads Redis first, then the database on a miss, then SET with a TTL. The database remains source of truth. The failure mode is stampede when the hot key expires and every instance refills at once.

Write-through updates Redis in the same request as the database write so the next read never sees a hole. Latency of the write path rises by a round trip. You still need TTL or eviction because cache and DB can diverge after partial failures.

Write-behind acknowledges the client after Redis, then flushes to the database asynchronously. Throughput looks great until Redis dies with unflushed writes. Treat it as a buffer with a documented loss window, not as durable storage.

A cache stampede is many clients missing the same hot key and slamming the database together. Locks with SET NX EX, probabilistic early expire, and TTL jitter are the usual defenses. Ignoring it shows up as periodic database CPU cliffs aligned with TTLs.

Negative caching stores a short-lived sentinel for not-found so a missing row is not queried thousands of times. TTL must be short or a newly created row stays invisible. Empty HASH versus a dedicated miss marker should be a team convention.

TTL jitter spreads expiry by adding a random delta so sibling keys do not evaporate on the same second. Without jitter, a deploy that SET the same TTL on a million keys creates an eviction storm. Keep the jitter small relative to the mean TTL.

LRU eviction via allkeys-lru or volatile-lru drops least-recently-used keys when maxmemory is hit. volatile-* only touches keys that already have a TTL. Picking noeviction on a cache is how SET starts returning OOM errors in production.

Probabilistic early expiration refreshes a key before TTL hits zero, with probability rising as remaining life shrinks. One client recomputes while others still serve the old value. It beats a hard lock when the fill is expensive but not catastrophic to duplicate.

A single-flight lock uses SET NX EX on a lock key so only one client recomputes the cache fill. Others sleep and retry GET. If the lock holder dies, EX is what unblocks the herd; a lock without TTL is a permanent outage.

CLIENT TRACKING enables client-side caching: the server invalidates a client local copy when watched keys change. BCAST and OPTIN change which keys are watched. Without TRACKING, a local Caffeine layer silently serves stale data after another pod writes.

volatile-ttl evicts keys closest to expiry among those that already have a timeout; allkeys-lfu and allkeys-lru can drop keys you meant to keep forever. Caches that mix durable config keys with cached rows need volatile-* so config is never evicted. Mixing policies in one instance is how sessions disappear.

Versioned key prefixes such as v3:user:42 let you invalidate a generation without SCAN. Bump the version in config and old keys expire via TTL or eviction. FLUSHDB as a cache-bust is a red flag on a shared Redis.

LFU via allkeys-lfu tracks frequency so a once-hot key that went idle is dropped before a steadily popular one. LRU would keep the recently scanned one-hit wonder. lfu-log-factor and lfu-decay-time are the knobs when the counter saturates.

maxmemory-policy noeviction is correct for Redis as a store: SET must fail rather than drop data. Caches want allkeys-lru or allkeys-lfu. Interviewers listen for that cache-versus-store split, not a memorized default.

Stampede at millions of QPS needs jittered TTL, request coalescing, and sometimes a stale-while-revalidate read of a still-present key. One NX lock becomes the new hotspot. Serve slightly stale from Redis while a background worker refreshes.

Durability of write-behind dies if AOF or RDB does not capture the buffer before a crash, and the async flusher has not reached the database. You then repair from logs or accept loss. Do not put payments on write-behind Redis.

Two-level caches require CLIENT TRACKING or very short local TTLs. Otherwise pod A serves a price that pod B already updated. Local caches without invalidation are the usual consistency bug in interviews.

RedisBloom BF.EXISTS before a database lookup cuts the negative-cache stampede for "does this email exist" at the cost of false positives. False positives mean an extra DB hit, not a wrong yes in billing. Size the filter with expected cardinality.

Refresh-ahead uses a worker that watches TTLs or a STREAM of invalidations and rewrites keys before they die. It is safer than every web thread racing to fill. The worker must be sharded or it becomes the stampede.

Cache-aside races are usually accepted: two SET of the same value are fine. WATCH plus MULTI is for compare-and-set on a value you cannot clobber, not for ordinary cache fills. Overusing Redis transactions here is a smell.