What they're testing
Whether you think about cache MISSES, and about many processes missing at the same instant.
The short answer~30 seconds
Cache-aside is the default: on read, try the cache, and on a miss read the DB and populate; on write, update the DB and DELETE the key rather than updating it. Deleting is safer than updating because two concurrent writes can land in the cache out of order. The biggest trap isn't staleness but the stampede: a hot key expires, five thousand requests miss simultaneously and all hit the database.
Cache-aside: try the cache first and return on a hit. While the TTL holds, the database receives almost nothing.
The long answer
There are three anti-stampede techniques, combinable. One is a lock: the first process to miss takes a short Redis lock and computes while the others wait or serve the stale value. Two is probabilistic early expiry: each request decides to refresh early with a probability that rises as expiry approaches, so refreshes spread out instead of stacking on one instant. Three is TTL jitter — add ±10% randomness so thousands of keys created together don't expire together.
On correctness, it's worth admitting plainly: cache-aside has a race window that can't be fully closed. One request misses, reads the DB, and BEFORE it writes to the cache another request updates the DB and deletes the key — so the first writes a stale value that then sits there for the full TTL. Low probability, non-zero. Mitigate with short TTLs, and for data that genuinely can't be stale, don't cache it.
At senior level the thing worth raising is key choice and granularity. Caching one small object by id gives a high hit rate and easy invalidation; caching a filtered, sorted result page gives a low hit rate and any change invalidates it. If you find yourself deleting by pattern (KEYS user:*), the key design is wrong — KEYS blocks Redis, and needing it usually means you should cache at a finer grain.
What they'll ask next
?Write-through versus write-behind?
Write-through writes both at once — the cache is always fresh, but every write is slower and you cache things nobody reads. Write-behind writes the cache first and flushes later — fastest and most dangerous, because losing the cache loses whatever hadn't flushed.
?Do you cache a value that doesn't exist?
Yes, and you should. Without negative caching, every request for a non-existent id reaches the database — that's cache penetration, and it's trivially weaponised. Cache a null with a short TTL, or put a Bloom filter in front of the valid id set.
These lose points
- Updating the cache instead of deleting the key, with no mention of write ordering. It's a persistent source of wrong data.
- Never mentioning the stampede. It's the first real incident every cache produces.
Sources
- Redis — Client-side caching and invalidation patterns
- Vattani, Chierichetti, Lowenstein — Optimal Probabilistic Cache Stampede Prevention (VLDB 2015)