Redis Overview: Features, Data Types, Persistence, Clustering, and Common Interview Questions

What is Redis?

Redis is a fully open‑source, BSD‑licensed, high‑performance in‑memory key‑value database.

Key characteristics compared with other key‑value cache products

Redis supports data persistence to disk, offers richer data structures beyond simple strings (including list, set, sorted set, hash, etc.), and provides master‑slave replication for backup.

Advantages of Redis

It delivers extremely high performance (approximately 110,000 reads per second and 81,000 writes per second), supports a variety of data types, guarantees atomic operations (both single commands and transactions via MULTI/EXEC), and includes features such as publish/subscribe, notifications, and key expiration.

How does Redis differ from other key‑value stores?

Redis offers more complex data structures with atomic operations, runs in memory while allowing persistence to disk, and provides a compact append‑only file format for efficient storage.

Redis data types

Redis supports five primary data types: string, hash, list, set, and sorted set (zset). Advanced users also use HyperLogLog, Geo, and Pub/Sub, and may explore modules such as BloomFilter, RedisSearch, and Redis‑ML.

Benefits of using Redis

1) Speed – data resides in memory, giving O(1) lookup and update complexity. 2) Rich data types – support for strings, lists, sets, zsets, hashes, etc. 3) Transactions – operations are atomic, either all succeed or none execute. 4) Versatile features – can be used for caching, messaging, and automatic key expiration.

Redis vs. Memcached

Redis supports richer data types, is faster, and provides persistence, whereas Memcached only stores simple strings in memory.

Is Redis single‑process single‑threaded?

Yes, Redis runs in a single process and uses an event loop to serialize concurrent requests, eliminating traditional locking overhead.

Maximum string size

The largest string value Redis can store is 512 MB.

Persistence mechanisms

RDB (Redis DataBase)

Creates point‑in‑time snapshots of the dataset and writes them to a temporary file that replaces the previous dump file.

Advantages of RDB

Single dump file, good disaster recovery, and minimal impact on the main process because a child process handles the I/O.

Disadvantages of RDB

Potential data loss between snapshots if a crash occurs.

AOF (Append‑Only File)

Logs every write command in the Redis protocol format, allowing full reconstruction of the dataset.

Advantages of AOF

Higher data safety (configurable appendfsync policies), ability to recover from crashes using redis-check-aof, and support for rewrite to compact the file.

Disadvantages of AOF

Larger file size and slower startup compared to RDB, especially with large datasets.

Common performance problems and solutions

Avoid writing RDB snapshots on the master during heavy load, enable AOF on slaves for critical data, keep master and slaves in the same LAN, limit the number of slaves on a busy master, and use a linear replication chain (master ← slave1 ← slave2 …) for easier failover.

Key expiration strategies

1) Timed deletion – a timer removes the key exactly when it expires. 2) Lazy deletion – keys are removed when accessed after expiration. 3) Periodic deletion – the server scans and deletes expired keys at intervals.

Eviction (reclamation) policies

volatile‑lru : evicts least‑recently‑used keys with an expiration set. volatile‑ttl : evicts keys that are about to expire. volatile‑random : evicts random keys with an expiration. allkeys‑lru : evicts least‑recently‑used keys among all keys. allkeys‑random : evicts random keys among all keys. no‑eviction : disables eviction.

When to use which policy

Use allkeys‑lru for workloads with a power‑law access pattern, and allkeys‑random for uniformly accessed data.

Why does Redis keep data in memory?

Storing data in memory provides the fastest read/write performance; persistence is handled asynchronously to avoid blocking the main thread.

Replication mechanisms

Redis supports master‑slave replication; the master performs a background save (BGSAVE) and streams subsequent writes to slaves, which load the snapshot and then replay the buffered commands.

Pipeline

Pipeline batches multiple commands to reduce round‑trip latency, improving QPS when commands are independent.

Redis clustering

Redis Sentinel provides high availability by promoting a slave to master on failure, while Redis Cluster offers horizontal scaling via sharding.

Cluster failure scenarios

In a three‑node cluster without replicas, losing a node that owns a slot range can render the entire cluster unavailable.

Java clients

Popular clients include Redisson, Jedis, and Lettuce; Redisson is the officially recommended client.

Jedis vs. Redisson

Jedis offers a comprehensive command API, while Redisson provides distributed Java data structures but lacks some low‑level features.

Setting and authenticating a password

Set password: config set requirepass 123456 Authenticate:

auth 123456

Hash slots in Redis Cluster

Redis Cluster uses 16,384 hash slots; each key’s CRC16 checksum modulo 16384 determines its slot, and each node is responsible for a subset of slots.

Cluster replication model

Each node has N‑1 replicas to maintain availability when some nodes fail.

Potential data loss in clusters

Redis does not guarantee strong consistency, so writes may be lost under certain failure conditions.

Finding many keys with a common prefix

Use KEYS prefix* for a quick scan (blocks the single thread) or SCAN for a non‑blocking incremental scan.

Mass expiration considerations

Setting many keys to expire at the same moment can cause short pauses; adding a random jitter to expiration times mitigates this.

Using Redis as an asynchronous queue

Typical pattern: push with RPUSH, pop with LPOP or block with BLPOP. For fan‑out, use Pub/Sub.

Distributed lock

Acquire lock with SETNX and set an expiration with EXPIRE (or combine using the extended SET command with NX and PX options).

Typical Redis use cases

1) Session cache – persistent, fast storage for user sessions. 2) Full‑page cache – improves page load times with durability. 3) Queues – list and set structures enable reliable message queues. 4) Leaderboards/counting – sorted sets support ranking and atomic increments. 5) Publish/Subscribe – real‑time messaging for chat, notifications, etc.

Scalability limits

Redis can theoretically handle up to 2³² keys and the same number of elements in lists, sets, and sorted sets, limited only by available memory.

Memory optimization

Prefer hashes to store related fields under a single key, reducing key count and memory overhead.

What happens when memory is exhausted?

Write commands return errors (reads still work); enabling an eviction policy can automatically remove older data.

Testing Redis connectivity

Use the PING command.

Understanding Redis transactions

Transactions are atomic blocks of commands executed sequentially without interruption; commands include MULTI, EXEC, DISCARD, and WATCH.

Setting key expiration and persistence

Use EXPIRE to set a TTL and PERSIST to make a key permanent.

Reducing memory usage

Leverage compact data structures (hashes, lists, sets, sorted sets) especially on 32‑bit instances.

Handling large keyspaces

When a keyspace contains billions of keys, use SCAN for incremental iteration and appropriate eviction policies to keep memory usage under control.

Conclusion

Redis is a versatile, high‑performance in‑memory database suitable for caching, messaging, ranking, and many other scenarios, with a rich set of features that make it a common topic in technical interviews.