Redis Interview Questions and Answers

Redis offers two persistence mechanisms.

RDB takes point-in-time snapshots at configured intervals, for example save 900 1 snapshots after 900 seconds if at least one key changed. RDB files are compact and fast to load, which is good for backups and restarts, but a crash loses writes since the last snapshot.

AOF appends every write command to a log. With appendfsync everysec Redis fsyncs once per second, a good balance; always is slowest but safest; no lets the OS decide. AOF grows over time and is compacted by rewrite, and you can enable AOF and RDB together.

On restart Redis prefers AOF because it is usually more complete. For pure caches you may disable persistence entirely and rely on the source of truth. Always test the restore path, not just the backup.

You set a time to live with EXPIRE, SETEX or PEXPIRE. Redis removes expired keys lazily on access and also runs a background sampling cycle that actively deletes expired keys. Expiry is per key and works with any data type.

Eviction happens when memory reaches maxmemory. Policies include:

• noeviction: reject writes, best when data must not be lost.
• allkeys-lru and allkeys-lfu: evict least recently or least frequently used keys across all keys, best for caches.
• volatile-lru, volatile-lfu and volatile-ttl: evict only keys with a TTL.
• allkeys-random and volatile-random: random eviction.

LRU in Redis is approximate, sampling a few keys rather than tracking perfect order. LFU tracks access frequency and suits skewed workloads. Choose allkeys-lru for a general cache and volatile variants if some keys must persist. Monitor evicted_keys and hit rate.

In cache-aside the application checks the cache first. On a miss it reads from the database, writes the value into the cache with a TTL, and returns it. On writes, the common approach is to update the database and then invalidate the cache key.

def get_user(uid):
    cached = redis.get(f"user:{uid}")
    if cached:
        return json.loads(cached)
    user = db.get_user(uid)
    redis.setex(f"user:{uid}", 300, json.dumps(user))
    return user

Consistency pitfalls: updating the cache before the database, or racing concurrent writers, can leave stale data. Delete the cache on write and let the next read repopulate it, using a short TTL as a safety net. For stronger needs use versioned keys or write-through. The first request after invalidation always pays the database cost.

Pub/Sub is fire-and-forget messaging. Publishers send to a channel and subscribers receive in real time, but messages are not stored. An offline subscriber misses them, and there is no acknowledgement or replay. It is simple and fast for live notifications where loss is acceptable.

Streams are a persistent, append-only log. Each entry has an id, and consumers can read ranges, replay history, and use consumer groups for at-least-once delivery with XACK acknowledgements. Pending entries can be claimed by another consumer if one fails, and XADD supports trimming with MAXLEN.

XADD orders * type "created" id 42
XREADGROUP GROUP workers c1 COUNT 10 BLOCK 5000 STREAMS orders >

Use Pub/Sub for ephemeral events and Streams for reliable event processing, audit logs or work queues that must survive restarts.

A stampede happens when a popular key expires and many clients simultaneously hit the database to rebuild it. Several mitigations exist.

• Locking or mutex: only the first request rebuilds while others wait briefly or serve stale data, using SET NX with a short TTL as a rebuild lock.
• Probabilistic early expiration: refresh before expiry with random jitter so rebuilds spread out.
• Stale-while-revalidate: serve the expired value while one worker refreshes in the background.
• TTL jitter: add a random offset so many keys do not expire at once.
• Request coalescing: deduplicate concurrent misses for the same key in-process.
• Never expire hot keys, refreshing them with a scheduled job.

Combine TTL jitter with a rebuild lock for most read-heavy systems, and monitor hit rate and database load during incidents.

Pipelining sends many commands in one network round trip without waiting for each reply, dramatically improving throughput for batch workloads since cost is dominated by round-trip time rather than execution.

pipe = redis.pipeline()
for k in keys:
    pipe.get(k)
results = pipe.execute()

Transactions use MULTI and EXEC to queue commands and run them as one isolated step without interleaving from other clients. WATCH provides optimistic locking: if a watched key changes before EXEC, the transaction aborts and the client retries.

WATCH balance:1
MULTI
SET balance:1 100
EXEC

Redis transactions are not rollback based: if one queued command fails at runtime the others still run. Use Lua scripts when you need atomic read-modify-write logic executed server-side.