Redis and Caching Strategies Interview Questions: Cache-Aside, Eviction and Cache Stampede

By Preeti Verma

Caching shows up in almost every backend and system design interview. It is the first answer to "this endpoint is slow", and also the source of some of the most interesting follow-up questions: what if the cache is stale, what if it goes down, what if a thousand requests miss at once?

This guide covers the questions you are most likely to get, with answers that go beyond "use Redis".

1. Why use a cache at all?

A cache keeps a copy of data in fast storage (usually memory) so you avoid repeating slow work: a database query, a remote call, a heavy computation. Benefits: lower latency, less load on the database, and a better chance of surviving traffic spikes. The cost is complexity and the risk of stale data, so a strong answer always mentions both sides.

Cache data that is read often, changes rarely, and is expensive to produce. Do not cache data that must always be perfectly current, such as an account balance used for a payment decision.

2. Explain the common caching patterns

  • Cache-aside (lazy loading): the application checks the cache first. On a miss, it reads the database, stores the result in the cache, and returns it. Writes go to the database and the cached entry is removed or updated. This is the most common pattern and the one to know best.
  • Read-through: the cache itself loads data from the database on a miss. The application only talks to the cache.
  • Write-through: every write goes to the cache and the database together. Reads are always fresh, but writes are slower.
  • Write-behind (write-back): writes go to the cache and are saved to the database later, in batches. It is fast, but you can lose data if the cache fails before it is flushed.

A good answer picks one for a scenario and explains the trade-off, for example: "I would use cache-aside for product details because reads dominate and a little staleness is fine."

3. How do you keep the cache and database consistent?

Be honest that this is hard. Common approaches:

  • Invalidate on write: delete the cached key when the data changes, so the next read reloads it.
  • Use a TTL (time to live): entries expire after a set time, which puts an upper limit on staleness.
  • Update the cache from the write path (write-through) when freshness matters more than write speed.

The classic race to mention: a reader loads old data from the database just before a writer updates it, then stores the old value in the cache after the writer's invalidation. A short TTL is a practical safety net for this.

4. What are eviction policies?

When the cache is full, something has to go. Common policies: LRU (least recently used), LFU (least frequently used), FIFO, and random. In Redis you set maxmemory and a policy such as allkeys-lru or volatile-ttl. Say that you would choose LRU as a sensible default, and LFU when a small set of items is requested much more often than the rest.

5. What are cache stampede, penetration and avalanche?

These three problems are asked constantly:

  • Stampede (thundering herd): a popular key expires, and many requests miss at once and all hit the database. Fixes: let only one request rebuild the value (a lock or request coalescing), refresh the value slightly before it expires, or add a little random jitter to TTLs.
  • Penetration: repeated requests for keys that do not exist, so every request goes to the database. Fixes: cache the "not found" result for a short time, or use a Bloom filter to reject impossible keys.
  • Avalanche: many keys expire at the same moment, or the cache goes down, and the database is flooded. Fixes: randomise TTLs, add replicas, and protect the database with rate limits and circuit breakers.

6. What data types does Redis support?

  • Strings: the basics, also counters (INCR).
  • Hashes: field-value maps, good for objects.
  • Lists: ordered, useful for queues and recent items.
  • Sets: unique members, useful for tags or "who liked this".
  • Sorted sets: members with scores, ideal for leaderboards and rate limiting windows.

Bonus: bitmaps, HyperLogLog for approximate unique counts, streams for event logs.

7. Why is Redis fast, and is it single-threaded?

Data lives in memory, it uses efficient data structures, and command execution is mostly single-threaded, which avoids locking overhead. Be precise: newer versions use extra threads for network input and output, but commands still run one at a time, so a single slow command can block everyone. Avoid commands such as KEYS * on big datasets.

8. How does Redis persist data?

  • RDB: point-in-time snapshots at intervals. Compact and fast to restore, but you can lose the latest changes.
  • AOF (append-only file): logs every write, so you lose less, at the cost of a bigger file and some speed.
  • You can use both. Many teams treat Redis purely as a cache and accept loss, which is a valid design choice if the data can be rebuilt.

9. How do you make Redis highly available and scale it?

  • Replication: a primary with replicas for reads and failover.
  • Sentinel: monitors the primary and promotes a replica if it fails.
  • Cluster: splits keys across many nodes (hash slots), so you can scale memory and throughput.

10. Can you use Redis as a distributed lock?

You can, with SET key value NX PX <ms> (set only if absent, with an expiry), and release the lock only if you still own it, using a unique value. Be honest about the limits: a lock can expire while the work is still running, and distributed locks have subtle failure cases. For strict correctness, use a mechanism that checks a version or fencing token in the data store itself.

11. How do you cache in Spring Boot?

Enable caching and use annotations: @Cacheable (read through the cache), @CacheEvict (remove on change) and @CachePut (update). Mention that you configure a real cache provider such as Redis, set TTLs, and that annotations rely on Spring's proxy, so calling a cached method from inside the same class bypasses the cache. This is the same proxy pitfall as with @Transactional.

12. What would you not cache?

  • Highly personal data, unless the cache key includes the user.
  • Anything where staleness is dangerous (permissions, payment state).
  • Data that is cheap to compute or changes on nearly every request.

A good habit is to cache after you have measured that a query is actually a bottleneck.

13. How do you measure whether a cache is working?

Track the hit rate, latency with and without the cache, memory use, eviction count and error rate. A low hit rate means the cache is adding cost without benefit.

Scenario questions to practise

  • "Your product page is slow. Walk me through adding a cache."
  • "A celebrity's profile expires from the cache and the database spikes. What happened and how do you fix it?"
  • "The cache is down. What should your application do?" (Fall back to the database with protection, rather than failing.)

Related reading: HTTP caching in REST API design, how to design a URL shortener (a read-heavy cache example), and how to design a rate limiter, which uses Redis counters.

Practise this on GenQuest

  • Start a voice mock interview: answer out loud to an AI interviewer that knows your resume and the role, get follow-up questions, then read a scored report with a question-by-question review. Your first 15-minute interview is free.
  • Open the question banks: Core Java scenarios, Blind 75 and NeetCode 150, high-level and low-level design questions, and company-wise sheets, with a free preview and progress tracking.
  • Ask the AI Coach: paste any question you are stuck on and get it explained in plain words, with a short answer you could say in an interview. See how it works in our AI Coach introduction.

FAQ

Redis or Memcached? Both are fast in-memory stores. Redis has richer data types, persistence and replication. Memcached is simpler. Many teams pick Redis for flexibility.

Is a local in-memory cache enough? For a single instance, yes. With several instances, each has its own copy, so they can disagree. A shared cache such as Redis keeps them consistent.

How long should a TTL be? As long as the data can safely be stale. Start from the business rule ("a price may be five minutes old"), not from a guess.

The takeaway

Know cache-aside, the three failure modes (stampede, penetration, avalanche), eviction and TTLs, and be honest about staleness. A candidate who explains how a cache can go wrong is more convincing than one who only says it makes things faster.