Redis Interview Questions: Caching Pitfalls, Persistence Options, Memory Optimization, and Eviction Policies

Redis common interview questions

1. Cache Penetration – Occurs when high‑concurrency users request data that does not exist in the database, potentially causing database crashes.

2. Cache Breakdown (Cache Stampede) – Happens when cached data expires under heavy load; the solution is to chain multiple Redis instances and stagger their expiration times by a few seconds to avoid simultaneous deletions.

3. Cache Avalanche – In a high‑concurrency environment many keys expire at the same moment, overwhelming the database; the mitigation is the same as for cache breakdown: stagger expiration times across Redis nodes.

4. Redis Persistence Issues

Problem description: Redis stores data in memory, so a shutdown or crash can lose cached data.

Persistence principle: Redis follows the persistence mode defined in its configuration file; the default is the RDB mode.

4.1 RDB mode – Periodic snapshotting; risk of data loss between snapshots. The snapshot file (default dump.rdb ) is the most efficient way to persist the current memory state.

Persistence commands:

save – Synchronous snapshot, may block ongoing operations.

bgsave – Asynchronous snapshot performed by a background process.

Typical save configurations:

save 900 1 – Persist if at least one change occurs within 900 seconds.

save 300 10 – Persist if at least ten changes occur within 300 seconds.

save 60 10000 – Persist if at least ten‑thousand changes occur within 60 seconds.

Frequent writes require shorter persistence intervals, but save 1 1 is discouraged because it can severely block the server.

4.2 AOF mode – Disabled by default; can be enabled by setting appendonly=yes in redis.conf . AOF logs every write operation, providing near‑real‑time persistence at the cost of larger file size and slower recovery. When AOF is enabled, RDB is ignored.

Key AOF configuration snippets:

appendonly=yes

appendfilename "appendonly.aof"

appendfsync always – Real‑time sync.

appendfsync everysec – Sync every second (slightly slower than RDB).

appendfsync no – Rely on the OS to flush.

Manual persistence can still be triggered with save (blocking) or bgsave (non‑blocking).

4.3 Choosing a persistence method – If occasional data loss is acceptable, prefer the faster RDB mode; otherwise, use AOF for durability.

Scenario question – After mistakenly running flushAll on a Redis server before a major sale, the recommended fix is to edit the AOF file to remove the flushAll command and restart Redis.

5. Redis Memory Optimization Strategies

Adjusting memory size – Edit redis.conf (around line 566) and set maxmemory <bytes> (e.g., # maxmemory 2gb ).

Eviction algorithms

LRU (Least Recently Used) – Removes the key that has not been accessed for the longest time.

LFU (Least Frequently Used) – Removes the key with the lowest access count, using a decay mechanism to avoid stale hot keys.

RANDOM – Randomly evicts keys when memory is exhausted.

Memory‑policy configuration (around line 597)

Uncomment and set maxmemory-policy to one of the following:

volatile-lru – LRU for keys with an expiration.

allkeys-lru – LRU for all keys.

volatile-lfu – LFU for keys with an expiration.

allkeys-lfu – LFU for all keys.

volatile-random – Random eviction for keys with an expiration.

allkeys-random – Random eviction for all keys.

volatile-ttl – Evicts keys with the shortest remaining TTL first.

noeviction – Returns an error when memory is full.

----------------------end---------------------