25 Advanced Redis Interview Questions for Senior Developers

Redis’s core command execution logic is single-threaded. It uses an event loop (based on I/O multiplexing like `epoll` or `kqueue`) to handle all client connections and commands on a single thread. This model avoids the complexity and overhead of locks and race conditions, simplifying the design and allowing for high throughput.

However, Redis is **not entirely single-threaded**. Since version 4.0, it uses background threads for certain slow operations, such as unlinking large keys (`UNLINK`), and I/O operations in newer versions (`io-threads`). This prevents these tasks from blocking the main event loop.

When Redis reaches its configured `maxmemory` limit, it needs a way to make room for new data. Eviction policies define this behavior:

• `noeviction` (default): Returns an error for write commands, making Redis read-only.
• `allkeys-lru`: Evicts the least recently used (LRU) keys from the entire keyspace.
• `volatile-lru`: Evicts the LRU keys only from those that have an expiration set.
• `allkeys-random`: Evicts random keys from the entire keyspace.
• `volatile-ttl`: Evicts keys with an expiration set, prioritizing those with the shortest time-to-live (TTL).
• `allkeys-lfu` / `volatile-lfu`: Evicts the least *frequently* used (LFU) keys.

They are needed to manage memory usage and prevent Redis from consuming all available system memory.

Read the documentation on Key Eviction Policies.

Pipelining is a client-side optimization where multiple commands are sent to the Redis server without waiting for the reply to each individual command. The server processes all the commands and sends all the replies back at once. This drastically reduces the number of network round trips between the client and server. Since round-trip time (RTT) is often a major source of latency, pipelining can significantly improve the performance of applications that need to send many commands in sequence.

Learn about Pipelining in the official docs.

A Sorted Set is implemented using a dual data structure: a **hash table** and a **skip list**.

• The hash table maps members to their scores. This allows for O(1) lookups of a member’s score.
• The skip list stores the members ordered by their scores. This allows for efficient O(log N) operations related to rank and order, like retrieving a range of members by score.

This dual structure provides the best of both worlds: fast access by member and fast access by score/rank.

Memory fragmentation occurs when the memory allocator has free memory available, but it’s not in large enough contiguous blocks to satisfy allocation requests. This can lead to Redis using more memory (`used_memory_rss`) than it reports for its data (`used_memory`), resulting in wasted space.

Mitigation strategies include:

• Using a memory allocator optimized for reducing fragmentation, like `jemalloc` (which is often the default).
• Restarting the Redis server, which allows the OS to reclaim the fragmented memory. This can be done gracefully on a replica before promoting it to primary.
• Activating memory defragmentation (`activedefrag yes`), which can attempt to defragment memory online but comes with a CPU cost.

Redis Streams are an append-only log data structure that can be used as a message broker.

Key differences from Pub/Sub:

• Persistence: Stream messages are persisted in memory and can be saved to disk. Pub/Sub is “fire-and-forget”; messages are lost if no subscribers are connected.
• History: Clients can read the history of a stream or read from any point in time. Subscribers to Pub/Sub only receive messages sent after they subscribe.
• Consumer Groups: Streams support consumer groups, allowing multiple consumers to collaboratively process a stream of messages, with each message being delivered to only one consumer in the group. This provides message guarantees and fault tolerance.

Streams are a much more robust and feature-rich option for building message-driven systems.

Read the introduction to Redis Streams.

A HyperLogLog is a probabilistic data structure used to estimate the cardinality (the number of unique elements) of a very large set. It does this with incredible memory efficiency, using only about 12 KB of memory to estimate cardinalities of billions of elements, with a standard error of less than 1%.

A practical use case is counting the number of unique daily active users on a high-traffic website. You can add every user ID to a HyperLogLog (`PFADD`) without worrying about memory usage, and then get the approximate unique count (`PFCOUNT`) at any time.

A Bitmap is not a separate data type but a set of bit-oriented operations on the String type. You can think of it as an array of bits. This is extremely space-efficient for tracking boolean states.

For example, to track daily user logins, you could have a bitmap for each day where the bit’s offset is the user’s ID. When a user logs in, you set their bit to 1 (`SETBIT day:2025-06-25 user_id 1`). You can then instantly get the total number of unique logins with `BITCOUNT`, or perform bitwise operations (`BITOP`) to find out how many users logged in on multiple consecutive days.

Geospatial indexes allow you to store and query coordinates (longitude, latitude). They are built on top of the Sorted Set data structure. Redis uses a technique called **Geohash**, which encodes a 2D coordinate into a single string. These geohash strings have a useful property: the longer the shared prefix between two geohashes, the closer they are geographically. These geohash values (converted to integers) are then stored as the “scores” in a sorted set, which allows for efficient range queries to find all points within a certain radius of a given coordinate (`GEORADIUS`, `GEOSEARCH`).

When a consumer in a group reads a message using `XREADGROUP`, the message is added to a Pending Entries List (PEL) for that consumer. The PEL tracks messages that have been delivered but not yet acknowledged. If the consumer processes the message successfully, it must call `XACK` to remove it from the PEL. If a consumer crashes, its pending messages remain in the PEL, allowing another consumer (or a recovery process) to claim them using `XCLAIM` and ensure they are not lost.

• RDB (Redis Database): Performs point-in-time snapshots of your dataset at specified intervals.
  • Pros: Creates compact, single-file snapshots perfect for backups. Faster for restarts as it loads a single file.
  • Cons: Can lose data between snapshots if Redis crashes. The `fork()` operation to create the snapshot can be CPU/memory intensive.
• AOF (Append Only File): Logs every write operation received by the server.
  • Pros: Much more durable; you can configure it to lose at most one second of data. The log is human-readable and can be repaired.
  • Cons: AOF files are typically larger than RDB files. Can be slower to restore compared to RDB, although this is mitigated by AOF rewriting.

It’s common to use both together for maximum durability.

Read the official documentation on Redis Persistence.

As the AOF file is an append-only log of commands, it can grow very large over time. AOF rewriting is a process that creates a new, minimal AOF file containing the shortest sequence of commands needed to rebuild the current dataset in memory. For example, if you have 100 `INCR` commands for a key, the rewritten AOF will just contain a single `SET` command with the final value. This is done in a background process to avoid blocking the main server.

Yes, you can disable both RDB and AOF persistence. This is appropriate when you are using Redis purely as a volatile cache. In this scenario, you don’t care if the data is lost on a restart, as the application can repopulate the cache from a primary data source (like a SQL database). Running without persistence can slightly improve performance by removing all disk I/O overhead.

Redis Sentinel is a high-availability solution for Redis. It is a separate process that runs alongside your Redis instances.

Its main responsibilities are:

1. Monitoring: Continuously checks if the primary and replica instances are working as expected.
2. Notification: Notifies system administrators or other programs via an API if something is wrong with one of the monitored instances.
3. Automatic Failover: If a primary is down, Sentinel will start a failover process where it promotes one of the replicas to be the new primary and reconfigures the other replicas to use it.
4. Configuration Provider: Acts as a source of authority for clients to ask for the address of the current primary.

Explore the Redis Sentinel documentation.

The quorum is the number of Sentinels that must agree that a primary is down before a failover process can be initiated. For example, if the quorum is 2, at least two Sentinels must independently detect the primary as unreachable. This prevents a single, isolated Sentinel (e.g., one with network issues) from incorrectly triggering a failover. To actually perform the failover, a Sentinel must still win a majority vote from all Sentinels in the cluster.

Redis Cluster provides a way to run a Redis installation where data is automatically sharded across multiple nodes.

• Scalability (Sharding): The keyspace is divided into 16,384 “hash slots.” Each primary node in the cluster is responsible for a subset of these slots. This allows you to distribute your data, memory usage, and load across multiple machines.
• High Availability: Each primary node can have one or more replicas. If a primary fails, one of its replicas can be promoted to become the new primary, ensuring the cluster remains available. Unlike Sentinel, there is no central authority; nodes communicate directly over a “cluster bus” to detect failures.

Read the Redis Cluster tutorial.

A hash slot is the fundamental unit of sharding in Redis Cluster. The entire keyspace is divided into 16,384 slots. To determine which slot a key belongs to, Redis computes a CRC16 hash of the key (or just the part enclosed in `{…}` for hash tags) and then calculates `CRC16(key) % 16384`. Each primary node in the cluster is responsible for a range of these slots. When a client sends a command, it can compute the hash slot to determine which node to send the command to.

A hash tag is a mechanism to force certain keys to be stored in the same hash slot. If a key contains a `{…}` pattern, only the string inside the curly braces is used to compute the hash slot. For example, the keys `{user:1000}:name` and `{user:1000}:email` will both be mapped to the same slot. This is crucial because it allows you to run multi-key operations (like transactions or Lua scripts) on these keys, which would otherwise be prohibited if the keys resided on different shards.

Redis transactions allow for the execution of a group of commands as a single, atomic operation. You start a transaction with `MULTI`, queue up your commands, and then execute them with `EXEC`.

However, they differ from traditional SQL transactions:

• No Rollback: If a command fails during execution (e.g., trying to `INCR` a string), Redis will report an error for that command, but it will continue to execute the rest of the commands in the queue. There is no automatic rollback.
• No Runtime Errors: A transaction will fail entirely before execution if there is a syntax error in one of the queued commands.

They primarily guarantee that no other client can interfere with the execution of the commands between `MULTI` and `EXEC`.

The `WATCH` command is used to implement optimistic locking, or a check-and-set (CAS) behavior. Before starting a `MULTI` block, you can `WATCH` one or more keys. If any of the watched keys are modified by another client before you call `EXEC`, the entire transaction will be aborted, and `EXEC` will return a null reply. This allows you to build complex atomic operations, like “update a value only if it hasn’t changed since I last read it.”

Lua scripting allows you to execute complex server-side logic atomically.

Advantages:

• Atomicity: The entire script is executed as a single, atomic operation. No other command can run concurrently, which simplifies complex read-modify-write patterns without needing `WATCH`.
• Performance: It reduces network latency by moving logic from the client to the server, often combining multiple commands into a single round trip. The scripts are also cached by Redis after the first run.
• Simplicity: Can be simpler and more powerful than using `WATCH`/`MULTI`/`EXEC` for conditional updates.

Read the introduction to Lua scripting.

A common and efficient method uses a Sorted Set. For each user/IP, you would store timestamps of their requests in a sorted set, with the score and value both being the timestamp.

To check the rate limit:

1. Remove all timestamps from the set that are older than the window (e.g., 1 minute ago) using `ZREMRANGEBYSCORE`.
2. Get the current count of requests in the window with `ZCARD`.
3. If the count is below the limit, add the new request’s timestamp to the set using `ZADD` and allow the request. Otherwise, reject it.

This entire sequence should be performed atomically using a Lua script to prevent race conditions.

Redlock is an algorithm for implementing a distributed lock manager on top of multiple Redis instances, aiming to provide a higher degree of safety than a single-instance lock.

Criticisms: It has been heavily criticized by distributed systems experts (most notably Martin Kleppmann). The core criticism is that it relies on assumptions about timing and network delays that do not hold in a real-world asynchronous network. It can fail to guarantee mutual exclusion under certain network conditions or when system clocks drift, potentially allowing two clients to hold the same lock. For this reason, many experts advise against using it for safety-critical applications.

Read about Distributed Locks with Redis.

You can store session data in a Redis Hash or String, using a unique session ID as the key. The session ID is given to the user in a cookie.

Benefits:

• Performance: Reading from Redis is much faster than from a SQL database.
• Scalability: It allows you to share session state across multiple backend servers, enabling horizontal scaling without needing “sticky sessions.”
• Flexibility: You can easily set an expiration (`EXPIRE`) on the session key to handle automatic timeouts.

Redis Modules are dynamically loadable extensions that allow you to extend Redis with new data types and commands, often written in C/C++ or Rust. This enables Redis to move beyond its core data structures and serve new use cases with native performance.

Examples include:

• RediSearch: A powerful full-text search and secondary indexing engine.
• RedisJSON: Adds a native JSON data type with JSONPath syntax for sub-document access.
• RedisGraph: A graph database module.
• RedisTimeSeries: A time-series data structure with features like downsampling and aggregation.