Redis interview questions and answers

Redis is an in-memory data structure store used as a cache, database, message broker and more. It is fast because data lives in RAM, commands run on a single main thread (no locks), it uses efficient data structures and an event loop with non-blocking I/O, and the protocol is simple. Newer versions add I/O threads for networking.

Strings (cache values, counters with INCR), Hashes (objects such as a user profile), Lists (queues, recent items), Sets (unique tags, followers), Sorted Sets (leaderboards, rate-limit windows, priority queues), Streams (event logs with consumer groups), Bitmaps and HyperLogLog (flags and approximate unique counts), Geospatial indexes (nearby search), plus JSON and vector types in Redis Stack / Redis 8.

RDB writes point-in-time snapshots at intervals: compact and quick to restart from, but you can lose the last few minutes. AOF logs every write, replayed on restart, with fsync every second as the usual balance; it is rewritten in the background to stay small. Many deployments use both, or none for a pure cache.

Use cache-aside: read Redis, on a miss load from the database and SET with a TTL; delete the key on writes. Set maxmemory and an eviction policy such as allkeys-lru. Pitfalls: stampedes on hot keys (use locks or early refresh), stale data from missed invalidations, huge keys, and treating the cache as a source of truth.

When a hot key expires, many requests may rebuild it at once. Prevent it with a short lock (SET lock NX PX) so one request rebuilds while others wait or serve stale data, refresh early before expiry, add random jitter to TTLs, and keep popular keys warm in the background.

Replicas connect to a primary, receive a snapshot, then a stream of write commands. Replication is asynchronous, so a failover can lose the last acknowledged writes; WAIT can require replicas to acknowledge. Replicas serve reads and provide redundancy.

Store sessions as hashes or strings keyed by a random session ID, set a TTL that refreshes on activity, keep only what is needed, use replication or a managed service for availability, and encrypt or sign cookie IDs. Invalidate on logout by deleting the key.

Fixed window: INCR a key per user and window with EXPIRE. Sliding window: a sorted set of request timestamps, removing old ones with ZREMRANGEBYSCORE and counting with ZCARD. Token bucket: a Lua script that refills and takes a token atomically. Atomicity matters, so use MULTI or Lua.

Pub/Sub is fire-and-forget: only connected subscribers get a message, and nothing is stored. Streams are an append-only log with IDs and consumer groups; messages are stored, can be read later, acknowledged (XACK) and claimed by another consumer if one fails. Use Streams for reliable processing, Pub/Sub for live notifications.

Sentinel provides high availability for a primary with replicas: it monitors, fails over automatically and tells clients the new primary, but data is not split. Cluster shards data across many primaries using 16,384 hash slots, each primary with replicas, giving horizontal scale and failover. Multi-key operations in Cluster need keys in the same slot (hash tags like {user:1}).

SET lock:resource <random-token> NX PX 30000 acquires it only if free, with an expiry so a crashed holder does not block forever. Release it with a Lua script that deletes only if the token matches, so you never remove someone else's lock. For safety-critical work, add fencing tokens; Redlock spreads the lock across several nodes but has debated guarantees.

When maxmemory is reached, Redis evicts by policy: noeviction (writes fail), allkeys-lru or allkeys-lfu (evict least recently / frequently used among all keys), volatile-lru/volatile-lfu/volatile-ttl (only keys with a TTL), or random variants. Caches usually use allkeys-lru or allkeys-lfu.

Members unique with a numeric score, kept ordered. They use a skip list plus a hash table, giving O(log n) inserts and range queries by score or rank (ZRANGE, ZRANK). Small sets use a compact listpack encoding.

Running several commands atomically on the server with EVAL or registered functions: no other command runs in the middle. It is used for rate limiters, compare-and-set logic and lock release checks, while saving network round trips.

Store a unique token as the lock value, and release with a Lua script that deletes the key only if the value still matches, so you never delete a lock another client acquired after yours expired.

Commands execute one at a time on a main thread, so each command is atomic, but a slow command (large KEYS, big SMEMBERS, heavy Lua) blocks everyone. Since Redis 6, I/O threads can handle network reads and writes, but command execution remains single-threaded.

Each group tracks delivered and acknowledged entries. XREADGROUP gives each message to one consumer in the group; pending entries remain until XACK. XAUTOCLAIM reassigns messages left pending by crashed consumers.

Expiration removes a key when its TTL ends (lazily on access and by a periodic sampler). Eviction removes keys when memory hits maxmemory, according to the policy, even if they have no TTL or have not expired.

MULTI queues commands and EXEC runs them in order without other clients' commands in between. There is no rollback: if one command fails at runtime, the others still run. WATCH adds optimistic locking: EXEC aborts if a watched key changed. Lua scripts are often simpler for atomic read-modify-write.

KEYS scans the whole keyspace in one blocking call, freezing the single main thread on large datasets. Use SCAN, which iterates in small batches with a cursor, and design key names so you can find things without scanning.

Use INFO memory and MEMORY USAGE, redis-cli --bigkeys or --memkeys to find large keys, set TTLs, pick compact types (hashes for small objects), avoid unbounded lists and sets, and watch the fragmentation ratio.

Sending many commands without waiting for each reply, then reading all replies together. It cuts network round trips dramatically for bulk work. Unlike MULTI, it is not atomic; it is purely a network optimisation.

Use lists with LPUSH and blocking BRPOP for simple queues, BLMOVE to a processing list for reliability, or Streams with consumer groups for acknowledgements and retries. Libraries like BullMQ add scheduling, retries and priorities on top.

Watch memory use and fragmentation, hit and miss ratio, evicted and expired keys, connected clients, ops per second, latency (LATENCY tools), slow log entries and replication lag. Alert on memory nearing maxmemory and rising evictions.

Compact per-ID flags, such as daily active users by user ID (SETBIT, BITCOUNT) or feature flags. Millions of users fit in a few megabytes, and bitwise operations combine days.

GEOADD stores longitude and latitude as a geohash score in a sorted set; GEOSEARCH finds members within a radius or box. Useful for nearby drivers or stores.

With tracking enabled, the server remembers which keys a client read and sends invalidation messages when they change, so the client can keep a local copy safely and avoid network round trips.

Redis Stack (and Redis 8 with the query engine) can index vector fields in hashes or JSON documents and run k-nearest-neighbour searches with filters, so it can serve as a vector store or semantic cache for AI apps. Redis 8 also adds a native vector set type.

In 2024 Redis moved from the BSD license to source-available licenses; the Linux Foundation forked the last open version as Valkey. Redis 8 later added AGPL as an option. Many cloud providers offer Valkey as a compatible alternative.

Never expose it to the internet, require authentication with ACL users and least-privilege command rules, enable TLS, rename or disable dangerous commands, and keep it on a private network.

1. AList
2. BSorted SetCorrect answer
3. CString
4. DHyperLogLog

Why: Sorted sets order members by score with ZADD and ZRANGE.

1. ASET key val NX PX 30000Correct answer
2. BSETNX key val TTL
3. CPUT key val
4. DINCR key

Why: SET with NX and PX is the standard lock / once-only write.

1. ASwap
2. BReplica
3. CRDB
4. DAOFCorrect answer

Why: The append-only file replays writes on restart.

1. AA short lock or early refreshCorrect answer
2. BRemoving TTLs
3. CMore replicas only
4. DKEYS *

Why: This avoids cache stampede.

1. AAsynchronousCorrect answer
2. BSynchronous
3. CDisabled
4. DTwo-phase

Why: WAIT can require acknowledgements.

1. ADEL the key always
2. BLet it expire only
3. CFLUSHALL
4. DDelete only if the stored token matches, in LuaCorrect answer

Why: Avoids deleting someone else's lock.

1. Aallkeys-lruCorrect answer
2. Bvolatile-ttl only
3. Cnone
4. Dnoeviction

Why: It evicts the least recently used keys across the whole keyspace.

1. AFLUSHALL
2. BMONITOR
3. CDUMP
4. DSCANCorrect answer

Why: SCAN iterates incrementally without blocking.

1. A16,384Correct answer
2. B65,536
3. C256
4. D1,024

Why: Keys map to one of 16,384 slots, spread across primaries.

1. AIt supports consumer groups
2. BIt guarantees delivery
3. CMessages are stored for offline subscribers
4. DOnly connected subscribers receive messagesCorrect answer

Why: Pub/Sub does not persist messages.

1. AXLEN
2. BXADD
3. CXACKCorrect answer
4. DXDEL

Why: XACK removes it from the consumer group's pending list.

1. ALinked list only
2. BBloom filter
3. CSkip list plus hash tableCorrect answer
4. DB-tree

Why: O(log n) operations.

1. ARUN
2. BSCRIPTCALL
3. CEVALCorrect answer
4. DEXEC

Why: Scripts run atomically.

1. ABRPOP
2. BXREADGROUPCorrect answer
3. CXRANGE
4. DSUBSCRIBE

Why: Each message goes to one consumer.

1. AKeys are evicted per policy (or writes fail)Correct answer
2. BRedis restarts
3. CData moves to disk
4. DNothing

Why: noeviction makes writes fail.

1. ACommands run on a single main threadCorrect answer
2. BRedis has no network
3. CReplication blocks
4. DKeys are encrypted

Why: Each command blocks the loop.

1. AOnly in Cluster
2. BYes, always
3. CNo, Redis has no rollbackCorrect answer
4. DOnly for strings

Why: Other commands still run.

1. ADisk writes
2. BKey size
3. CMemory
4. DNetwork round tripsCorrect answer

Why: Many commands share one round trip.

1. AHash
2. BList
3. CSet
4. DHyperLogLogCorrect answer

Why: HyperLogLog estimates cardinality with a fixed small size.

1. AUsing KEYS
2. BDisabling replicas
3. CKeys in the same hash slot via hash tagsCorrect answer
4. DAny keys work

Why: Hash tags like {user:1} put keys in one slot.

1. AXDEL
2. BXTRIM
3. CXLEN
4. DXAUTOCLAIMCorrect answer

Why: Recovers work from crashed consumers.

1. ASADD only
2. BSETBIT and BITCOUNTCorrect answer
3. CLPUSH and LLEN
4. DHSET and HLEN

Why: One bit per user.

1. AHGETALL
2. BGEOSEARCHCorrect answer
3. CZRANGE
4. DSCAN

Why: Geo data lives in a sorted set.

1. ALRANGE
2. BLINDEX
3. CBRPOPCorrect answer
4. DRPOP

Why: Waits until an item arrives.

1. AMONITOR only
2. BINFO keyspace
3. CPING
4. DSLOWLOGCorrect answer

Why: Find commands blocking the server.

1. ALarge keys
2. BAuth errors
3. CMany keys expiring at onceCorrect answer
4. DReplication lag

Why: Spreads cache rebuilds.

1. AINCRCorrect answer
2. BADD
3. CPLUS
4. DSETRANGE

Why: INCR is atomic, so concurrent clients never lose updates.

1. AMonitoring and automatic failoverCorrect answer
2. BCompressing keys
3. CRunning Lua
4. DSharding data

Why: Sentinel promotes a replica if the primary fails.

1. AA Redis GUI
2. BA Redis client
3. CA cloud region
4. DAn open-source fork of RedisCorrect answer

Why: Forked in 2024.

1. ACLIENT LIST
2. BACLCorrect answer
3. CSELECT
4. DCONFIG GET

Why: Least-privilege access.