Redis Interview Essentials: Top Questions & Expert Answers

1. Benefits of Using Redis

Fast because data resides in memory, similar to a HashMap with O(1) lookup and operation complexity.

Supports rich data types: string, list, set, sorted set, hash.

Atomic transactions ensure operations are all‑or‑nothing.

Versatile features enable caching, messaging, and key expiration with automatic deletion.

2. Advantages of Redis over Memcached

Redis supports richer data structures beyond simple strings.

Redis is generally faster than Memcached.

Redis provides persistence capabilities.

3. Common Redis Performance Issues and Solutions

Avoid writing RDB snapshots or AOF logs on the master during heavy load.

For critical data, enable AOF on a slave with a one‑second sync policy.

Keep master and slaves in the same LAN to reduce replication latency.

Do not add slaves to an already stressed master.

Prefer a linear replication chain (master ← slave1 ← slave2 …) for stability.

4. Ideal Scenarios for Redis

Redis excels in any in‑memory use case. Although it offers persistence, it is primarily used as a fast, disk‑backed cache rather than a traditional durable store.

5. Additional Redis Features

Supports lists, sets, sorted sets, hashes, and more.

Provides master‑slave replication for data backup.

Offers persistence to disk, allowing data reload after restart.

6. Managing Large Keysets and Hot Data

When storing only a subset (e.g., 200 k keys) of a larger dataset (e.g., 2 000 k), configure eviction policies (volatile‑lru, allkeys‑lru, etc.) to keep hot data in memory.

7. Finding Keys with a Common Prefix

Use the KEYS command to list keys matching a pattern, but on a production server it blocks the single Redis thread. Prefer SCAN for non‑blocking iteration, handling possible duplicates in the client.

8. Common Performance Problems and Fixes

RDB snapshotting (via SAVE) blocks the master; avoid large snapshots during peak traffic.

AOF rewriting ( BGREWRITEAOF) consumes CPU and memory; monitor and schedule during low load.

Master‑slave replication benefits from LAN proximity.

9. Redis Data Structures

String, Hash, List, Set, Sorted Set; advanced users may also use HyperLogLog, Geo, Pub/Sub, BloomFilter, RedisSearch, Redis‑ML, etc.

10. Implementing Distributed Locks with Redis

Typical pattern: SETNX to acquire the lock, then EXPIRE to set a timeout. Modern Redis supports the atomic SET key value NX EX seconds command.

11. Using Redis as an Asynchronous Queue

Use a list: RPUSH to enqueue, LPOP to dequeue. If blocking behavior is needed, BLPOP waits for messages. For fan‑out, employ Pub/Sub, noting that messages are lost if subscribers are offline.

12. Bulk Expiration Considerations

Setting many keys to expire at the same moment can cause a short pause; add a random offset to spread expirations over time.

13. Why Redis Stores All Data in Memory

In‑memory storage yields the fastest read/write performance; data is asynchronously persisted to disk. When memory limits are reached, new writes are rejected unless configured otherwise.

14. Persistence Mechanisms in Redis

RDB creates point‑in‑time snapshots; AOF logs every write operation. Combining both gives durability (AOF) and fast restart (RDB). Sync frequency of AOF determines potential data loss on power failure.

15. Types of Persistence Offered

RDB snapshots at configured intervals.

AOF logs every write, with optional background rewriting.

In‑memory only (no persistence).

Both RDB and AOF enabled; on restart, AOF is loaded first.

16. Choosing the Right Persistence Strategy

For PostgreSQL‑level safety, enable both RDB and AOF. If occasional data loss of a few seconds is acceptable, RDB alone may suffice. RDB snapshots simplify backups and restore speed.

17. Benefits of Pipelining

Pipelining batches multiple commands into a single network round‑trip, boosting QPS when commands are independent.

18. Redis Replication and Synchronization

Initial sync: master performs BGSAVE, streams the RDB file to the replica, then streams subsequent write commands from a buffer for replay.

19. High Availability and Clustering

Sentinel provides automatic failover by promoting a slave to master. Redis Cluster enables horizontal scaling via sharding when a single instance cannot hold all data.

20. Maximum Number of Keys and Elements

Redis can theoretically handle up to 2³² keys; tests have stored over 250 million keys in a single instance. Lists, sets, and sorted sets can each hold up to 2³² elements, limited only by available memory.

21. Scaling Redis for Cache vs Persistent Store

For cache use, apply consistent hashing for dynamic scaling.

For persistent storage, a fixed key‑to‑node mapping is required; dynamic rebalancing is only supported by Redis Cluster.