Caching and Redis Interview Questions

Model answer

The application talks to both the cache and the database; the cache never talks to the database itself.

Read: look in the cache. On a hit, return it. On a miss, read from the database, put the result in the cache with a TTL, and return it.

Write: write to the database, then remove (or update) the cache entry so the next read fetches the fresh value.

It is the most common pattern because the cache only ever holds data someone asked for, and if the cache goes down the app still works, just slower.

Model answer

Usually the write never touched the cache and the old entry lives until its TTL runs out, or one code path updates the database without clearing the cache.

Delete is the safer choice. If two writers update the database and then each sets the cache, the sets can land in the opposite order to the database writes, leaving the cache holding the older value indefinitely. Deleting is the same whatever the order: the next reader loads whatever the database holds.

Delete *after* the database commit, not before; deleting first lets a reader refill the cache with the old value in the gap.

Model answer

Reader R misses the cache and reads the old value from the database. Before R writes it to the cache, writer W updates the database and deletes the cache key. Then R, a little late, puts the old value into the cache. It now stays stale until the TTL.

Ways to close or shrink it:

• Always set a TTL, so any stale entry heals itself. This alone is enough for most data.
• Store a version with the value and only write if it is newer (a Lua script in Redis can compare and set).
• Delayed double delete: delete again a second or so after the write.
• Invalidate from the database's change stream (CDC, for example Debezium), so deletes follow the commit order.

Model answer

A cache stampede (thundering herd): every request in the next few hundred milliseconds misses at once, and thousands of identical queries hit the database together, sometimes taking it down, which then keeps the cache empty.

Fixes:

• Single-flight: only one request rebuilds the value, using a short lock (SET lock NX PX 5000); the others wait briefly or get the old value.
• Stale-while-revalidate: keep serving the expired value while one background job refreshes it.
• Early refresh: refresh a hot key before it expires, either on a timer or with probability rising as expiry nears.
• Jittered TTLs, so keys cached at the same moment do not all expire at the same moment.

Model answer

Redis keeps its data in memory, and runs commands on a single thread, so each command is simple and atomic with no locking. Network round trips, not the commands, are usually the cost, which is why pipelining helps.

Leaderboard: a sorted set. ZADD board 1500 user:42 sets a score; ZREVRANGE board 0 9 WITHSCORES gives the top ten and ZREVRANK a player's position, all in O(log n).

Sessions: a hash per session (HSET session:abc userId 42 role admin) with EXPIRE for the timeout, or a plain string holding JSON. Refresh the TTL on each request for a sliding expiry.

Model answer

It depends on maxmemory-policy. The default is noeviction: reads still work, but writes fail with an out-of-memory error, which surprises teams who assumed Redis drops old keys by itself.

• allkeys-lru / allkeys-lfu: evict the least recently / least frequently used key from all keys. The usual choice for a pure cache.
• volatile-lru / volatile-lfu / volatile-ttl: evict only keys that have a TTL, which protects data stored without one.
• allkeys-random / volatile-random: evict at random.

If one Redis holds both cache entries and things that must not vanish (sessions, locks, queues), split them into separate instances with different policies rather than relying on TTLs to tell them apart.

Model answer

With no persistence configured, everything in memory is gone.

RDB writes a point-in-time snapshot to disk every so often (a forked child process does it). Restarts are fast, but you lose everything since the last snapshot.

AOF appends every write command to a log, replayed on start. With appendfsync everysec you lose at most about a second; the file grows and is rewritten in the background.

Many run both. For a pure cache, losing it can be fine, as long as the database can survive the burst of misses afterwards; warm the cache or rate-limit rebuilds if it cannot.

Model answer

For more reads, add replicas. For more memory or writes, use Redis Cluster, which splits keys across 16,384 hash slots spread over several primaries, each with replicas for failover.

What breaks:

• Multi-key commands and transactions only work when all keys are in one slot. Force it with a hash tag: {user:42}:cart and {user:42}:orders share a slot because only user:42 is hashed.
• Replication is asynchronous: a primary can acknowledge a write and die before the replica gets it, so a failover can lose recent writes.
• Hot keys do not spread: one very popular key lives on one node. Split it into several keys or cache it locally in the application for a second.

Model answer

max-age=3600: the response may be reused for an hour without asking the server. s-maxage sets a different lifetime for shared caches such as CDNs.

no-cache: it may be stored, but must be revalidated with the server before each use (a cheap request with If-None-Match and the ETag, answered with 304 Not Modified when unchanged). The name misleads many people.

no-store: never store it anywhere. For responses with personal or sensitive data.

Model answer

Put a content hash in the filename: app.3f9a2c.js. A changed file gets a new name, so it can be cached forever: Cache-Control: public, max-age=31536000, immutable. Next.js and Vite do this by default.

The HTML that points to those files is the one thing that must stay fresh: serve it with no-cache (or a very short max-age), so every visit learns the new filenames.

Keep the old hashed files available for a while after a deploy, so a user with the old HTML open does not get 404s when it lazy-loads a chunk.

Model answer

The danger is serving one user's data to another: if /api/me is cached by URL alone, the second visitor gets the first visitor's profile. It has happened to real companies.

Mark personal responses Cache-Control: private (browser only) or no-store. CDNs by default do not cache responses that set cookies or requests carrying an Authorization header, but do not rely on defaults; set it explicitly.

To cache variants safely, the varying input must be in the cache key: Vary: Accept-Language, or a CDN rule that keys on a header. Never vary on the session cookie; that just stores a copy per user.

The real win is splitting responses: cache the public part (product details) at the CDN and fetch the small personal part (cart count) separately.

Model answer

• Purge on change: when the price changes, call the CDN's purge API. Tag responses with surrogate keys (Surrogate-Key: product-42, or Cache-Tag) so one call clears every page that shows that product.
• Short TTL with stale-while-revalidate: s-maxage=10, stale-while-revalidate=60 keeps the origin load low while capping staleness near 10 seconds.
• Do not cache the price: cache the page, fetch the price from an uncached endpoint.

Purges are not instant everywhere (seconds across all edge locations) and can fail, so pair them with a modest TTL as a backstop. And for checkout, read the price from the database: the cached one is for display.