40 Must‑Know Redis Interview Questions to Ace Your Next Job

To help candidates prepare for Redis interviews, we compiled 40 common questions covering fundamentals, data types, persistence, clustering, performance, and practical usage.

1. What is Redis?

Redis is an open‑source, BSD‑licensed, high‑performance key‑value database.

Supports data persistence to disk.

Provides rich data structures such as list, set, sorted set, and hash.

Offers master‑slave replication for data backup.

Advantages of Redis

Very high read/write speed (≈110,000 ops/s read, 81,000 ops/s write).

Rich data types: strings, lists, hashes, sets, sorted sets.

All operations are atomic; transactions are supported via MULTI/EXEC.

Additional features: publish/subscribe, notifications, key expiration, etc.

2. Redis data types

Redis supports five primary data types: string, hash, list, set, and sorted set. Advanced structures such as HyperLogLog, Geo, and Pub/Sub are also available, and modules like BloomFilter, RedisSearch, and Redis‑ML can be used.

3. Benefits of using Redis

In‑memory speed comparable to a HashMap (O(1) operations).

Supports a variety of data structures.

Atomic operations and transaction support.

Features for caching, messaging, and key expiration.

4. Redis vs. Memcached

Redis supports richer data types.

Redis is generally faster.

Redis provides persistence.

5. Differences between Memcached and Redis

Memcached stores all data only in memory; Redis can persist to disk.

Redis offers complex data structures; Memcached only supports simple strings.

Redis uses its own VM mechanism, reducing system‑call overhead.

6. Single‑process, single‑threaded model

Redis runs in a single process and thread, converting concurrent requests into serialized operations via an internal queue.

7. Maximum size of a string value

512 MB.

8. Persistence mechanisms

Redis provides two persistence options:

RDB (snapshot)

Creates a dump file at intervals; fast startup, low I/O impact.

Potential data loss between snapshots.

AOF (append‑only file)

Logs every write command; can be configured for always, every‑second, or no‑sync.

Higher durability but larger files and slower recovery.

9. Common performance issues and solutions

Avoid large RDB snapshots on the master; they block the event loop.

Enable AOF on slaves for reliable backup.

Place master and slaves in the same LAN for low latency.

Prefer a linear replication chain (master←slave1←slave2…) to simplify failover.

10. Expiration key deletion strategies

Timed deletion (timer triggers at expiration).

Lazy deletion (check expiration on access).

Periodic deletion (background scan).

11. Eviction policies

volatile‑lru, volatile‑ttl, volatile‑random.

allkeys‑lru, allkeys‑random.

no‑eviction (disable eviction).

Choose policies based on data access patterns (e.g., LRU for skewed access, random for uniform access).

12. Why store all data in memory?

In‑memory storage provides the fastest read/write performance; persistence is handled asynchronously to disk.

13. Synchronization mechanism

Redis uses asynchronous master‑slave replication; the master creates a snapshot (RDB) and streams subsequent writes to replicas.

14. Benefits of pipelining

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

15. Redis cluster and Sentinel

Sentinel provides high availability by promoting a slave to master on failure.

Cluster provides horizontal scalability via hash slots (16384 slots) and sharding.

16. Scenarios that can render a cluster unavailable

If a node responsible for a range of hash slots fails without a replica, the cluster may lose those slots and become unavailable.

17. Java clients

Redisson, Jedis, Lettuce, etc.; the official recommendation is Redisson.

18. Jedis vs. Redisson

Jedis offers full command coverage; Redisson provides distributed Java data structures but lacks some features such as sorted set operations.

19. Setting and authenticating a password

Set password: CONFIG SET requirepass 123456 Authenticate:

AUTH 123456

20. Hash slots concept

Redis Cluster uses 16384 hash slots; each key’s CRC16 modulo 16384 determines its slot.

21. Master‑slave replication model

Each master can have N‑1 replicas to ensure availability when some nodes fail.

22. Possibility of write loss in a cluster

Redis does not guarantee strong consistency; under certain conditions writes may be lost.

23. Replication between cluster nodes

Asynchronous replication.

24. Maximum number of nodes in a cluster

16384.

25. Database selection in a cluster

Cluster mode only supports database 0.

26. Testing connectivity

Use the PING command.

27. Understanding Redis transactions

Transactions are atomic sequences of commands executed without interleaving from other clients; either all succeed or none are applied.

28. Transaction commands

MULTI

, EXEC, DISCARD, WATCH.

29. Setting expiration and persistence

EXPIRE

sets a TTL; PERSIST removes the TTL.

30. Memory optimization tips

Prefer hashes to store related fields together, reducing the number of keys and memory overhead.

31. How the eviction process works

When memory usage exceeds maxmemory, Redis applies the configured eviction policy to free space.

32. Reducing memory usage

On 32‑bit instances, pack data into compact structures like hashes, lists, sets, and sorted sets.

33. What happens when memory is exhausted

Write commands return errors; reads continue. With an eviction policy, old keys are removed automatically.

34. Key and collection limits

Redis can handle up to 2³² keys; each list, set, or sorted set can also hold up to 2³² elements, limited by available memory.

35. Keeping only hot data in Redis

Use appropriate eviction policies (e.g., volatile‑lru) to retain frequently accessed keys.

36. Ideal use cases

Session caching.

Full‑page caching.

Message queues (list, blpop, etc.).

Leaderboards and counters (sorted sets).

Publish/subscribe for real‑time notifications.

37. Finding keys with a common prefix

Use KEYS pattern for a quick scan (not recommended in production) or SCAN for a non‑blocking iteration.

38. Setting many keys to expire simultaneously

Distribute expiration times with a random offset to avoid a sudden load spike.

39. Implementing an asynchronous queue

Use a list with RPUSH to enqueue and LPOP or BLPOP to dequeue; for fan‑out, use Pub/Sub.

40. Distributed lock with Redis

Acquire a lock with SETNX followed by EXPIRE, or use the atomic SET key value NX EX seconds command.