Top 50 Redis Interview Questions in 2026 (With Real Answers)
Redis sits behind most production backends. Cache for slow queries. Rate limiter. Session store. Pub/sub. Streams for event processing. Leaderboards. Distributed locks. The 2024 license change spawned the Valkey fork, and by 2026 there's real production adoption of both.
These are the 50 Redis questions that come up in backend, infrastructure, and system design interviews in 2026.
Fundamentals (1-10)
1. What is Redis and what is it good for?
An in-memory key-value store with rich data structures. It's good for anything where latency matters and the dataset fits in RAM (or can be sharded across nodes that fit in RAM). The classic uses: cache, sessions, queues, leaderboards, rate limiters, pub/sub.
2. Redis vs Memcached - when do you pick which?
Memcached is simpler - just KV strings, no persistence, no replication. Redis has persistence, replication, clustering, Streams, scripts, and a dozen data structures. Memcached is fine for pure cache; Redis is the default everywhere else. New projects rarely pick Memcached.
3. What's Valkey and why does it exist?
A fork of Redis 7.2.4 created in March 2024 after Redis Inc. switched the OSS Redis license from BSD to dual SSPL/RSAL. Valkey is BSD-licensed, governed by the Linux Foundation, and backed by AWS, Google, Oracle, Ericsson. By 2026 it's at feature parity for most use cases and is the default in many distros and cloud services.
4. Should you use Redis or Valkey in 2026?
Depends on context. Cloud-managed services (AWS ElastiCache, GCP Memorystore) ship Valkey by default. Redis Inc.'s commercial features (Redis Cloud, Redis Enterprise) only exist on the Redis fork. Most apps don't care - the protocol and most commands are identical.
5. What data structures does Redis support?
Strings, Lists, Hashes, Sets, Sorted Sets, Bitmaps, HyperLogLogs, Geospatial indexes, Streams, JSON (RedisJSON), Vectors (RediSearch), Bloom filters (RedisBloom). The first six are core; the rest are modules or built-ins added in recent versions.
6. What's the difference between Strings and Hashes?
Strings store one value per key. Hashes store a map of fields to values under one key. Use a hash when you have related fields you want to manipulate together (e.g., a user's profile fields). Saves keys and lets you update individual fields without rewriting the whole blob.
7. When do you use Lists vs Streams?
Lists - simple FIFO/LIFO queues. LPUSH/RPOP. No history, message gone after consume. Streams - persistent event log with consumer groups, IDs, and replayable history. For real queue/event processing, Streams. For ephemeral task queues, Lists are fine and cheaper.
8. Sorted Sets - what's the killer use case?
Leaderboards. Each element has a score; the set is automatically ordered. ZADD leaderboard 100 alice, ZRANGE leaderboard 0 9 REV WITHSCORES for the top 10. Also great for time-ordered indexes (use timestamp as score).
9. What's the time complexity of Redis commands?
Most are O(1) or O(log N). Some are O(N) - KEYS, SMEMBERS on large sets. Redis is single-threaded for command execution; an O(N) command on a 10M-item set blocks the server for everyone. KEYS is a footgun - use SCAN instead.
10. Why is Redis fast?
In-memory. Single-threaded event loop (no lock contention). Simple binary protocol (RESP). Optimized C data structures. Network IO multiplexed via epoll/kqueue. The result: sub-millisecond p99 for single-key operations.
Persistence and Durability (11-20)
11. RDB vs AOF - what's the difference?
- RDB - periodic point-in-time snapshots of the dataset. Compact, fast restore, can lose data between snapshots.
- AOF (Append-Only File) - logs every write command. Larger file, slower restart, more durable.
Best practice: enable both. RDB for fast recovery, AOF for minimal data loss.
12. What's appendfsync and what are the choices?
Controls when AOF writes are fsync'd to disk.
always- every write fsync'd. Slowest, most durable.everysec- fsync once per second. Default. Loses up to 1s of writes on crash.no- let the OS decide. Fastest, least durable.
13. How does AOF rewrite work?
Over time, the AOF grows because every write is logged. AOF rewrite generates a new compact AOF representing the current state, then atomically replaces the old one. Triggered automatically by size growth or manually with BGREWRITEAOF.
14. What's the impact of BGSAVE on a busy server?
It forks a child process that snapshots memory. The fork itself is O(1) thanks to copy-on-write, but if your server is doing heavy writes, COW will dirty pages and memory usage can briefly double. On large instances, this is a real planning consideration.
15. Can Redis lose data?
Yes. Default config + a power loss = up to 1s of writes lost. Even with appendfsync always, you can lose the last in-flight commands. Redis is not a primary database for critical writes - it's a fast cache or an at-most-recent-second store.
16. How do you handle Redis as a primary store anyway?
Combine: AOF with appendfsync always, replication with WAIT to confirm propagation, and run on durable storage. Even then, accept that Redis trades some durability for speed - if you can't, use Postgres or a real database.
17. What's WAIT?
A command that blocks until a write has been replicated to N replicas. WAIT 2 1000 - wait for 2 replicas or 1000ms. Gives you a stronger durability guarantee than fire-and-forget replication. Doesn't make Redis a CP system, but reduces failover data loss.
18. Replication - how does it work in Redis?
Asynchronous primary-replica. Primary streams writes to replicas. Replicas can serve reads. On primary failure, you promote a replica (manually or with Sentinel). No automatic split-brain protection without Sentinel or Cluster.
19. What is Redis Sentinel?
A high-availability layer for non-clustered Redis. Sentinels monitor primary and replicas; on primary failure, they elect a replica to promote and update clients via the Sentinel API. Used when you need HA but a single primary is enough capacity.
20. Sentinel vs Cluster - which do you pick?
- Sentinel - single primary, multiple replicas. Simpler. Up to ~100K ops/sec on one box.
- Cluster - sharded across multiple primaries. Required for capacity beyond one machine.
Most apps don't need Cluster. Sentinel + a beefy box is enough. Adopt Cluster when you can't.
Clustering and Scaling (21-30)
21. How does Redis Cluster shard data?
By hash slot. The keyspace is divided into 16384 slots. Each key's slot is CRC16(key) % 16384. Nodes own ranges of slots. Clients use the slot map to route commands directly to the right node.
22. Can you do multi-key operations across slots?
No. Multi-key commands (MGET, MSET, transactions, scripts) require all keys in the same slot. Use hash tags - {user:42}:profile and {user:42}:sessions hash to the same slot because the {...} is what's hashed.
23. What happens when a Cluster node fails?
If it had replicas, one is promoted. If not, the slot range becomes unavailable. Clients get CLUSTERDOWN errors for keys in those slots. Cluster operates in a "majority must agree" model for slot reassignment, similar to Raft.
24. How do you add capacity to a Cluster?
Add new nodes, then rebalance slots from existing nodes to the new ones (redis-cli --cluster reshard). Slot migration is online but adds load. Plan for a few percent of throughput drop during migration.
25. Read replicas in Cluster - can clients use them?
By default, replicas in Cluster don't serve reads. Enable with READONLY per connection, but be aware reads from replicas are stale. Most clients route everything to primaries.
26. What's the right way to scale reads?
(1) Replicas with stale-read tolerance. (2) Read-through caching at a higher layer. (3) Cluster for sharding. (4) Cache the cache (local in-process cache with TTL). The first thing to ask: are reads actually the bottleneck, or are you hot-keying one slot?
27. What's a hot key and how do you handle it?
A single key with disproportionate traffic. Saturates one shard's CPU. Solutions: (1) shard the key by appending :N and letting clients pick a shard, (2) cache it locally in the app for short TTLs, (3) use MULTI + replication to amortize, (4) precompute and write through.
28. What's CROSSSLOT error?
You tried a multi-key command where keys hash to different slots. Use hash tags or restructure to keep related keys colocated. CROSSSLOT errors at high volume mean your data layout is wrong for Cluster.
29. How does Cluster handle resharding online?
Slots are migrated one at a time. Migrating slots are in MIGRATING state on the source and IMPORTING on the destination. Reads/writes during migration are routed via ASK redirects. Clients handle this transparently.
30. How big can a Redis instance get?
In-memory, so RAM is the cap. AWS ElastiCache offers up to ~635 GB per node. Bigger than that, you shard. The practical answer: under 50GB per node is comfortable; above 100GB, restart times and snapshot durations become operational pain.
Operations and Production (31-40)
31. Eviction policies - which one do you pick?
noeviction- errors when fullallkeys-lru- evict least-recently-used across all keysallkeys-lfu- evict least-frequently-used across all keysvolatile-lru/volatile-lfu- same but only keys with TTLvolatile-ttl- evict the soonest-to-expire
For pure cache, allkeys-lfu. For cache-with-some-permanent-keys, volatile-lfu. Default noeviction is rarely what you want.
32. What's the difference between TTL and EXPIRE?
TTL key returns seconds remaining. EXPIRE key seconds sets the TTL. PERSIST key removes the TTL. Idiomatic Redis caching: SET key value EX 3600 (set with TTL atomically).
33. Pipelining - what is it and why use it?
Send multiple commands without waiting for replies, then read all replies at once. Reduces round-trips. For batch operations, the difference between 1000 round-trips and 1 round-trip is the difference between 100ms and 1ms.
34. Pipelining vs MULTI/EXEC - same thing?
No. Pipelining is a network optimization - commands are still executed normally. MULTI/EXEC is a transaction - commands execute atomically as a unit. You can pipeline a transaction. But "transactional" in Redis is weaker than ACID - no rollback on logical errors, only on syntax errors during queueing.
35. What's WATCH and how does it relate to transactions?
Optimistic locking for transactions. WATCH key marks a key; if it changes between WATCH and EXEC, EXEC returns nil and you retry. Used for compare-and-set patterns: read, decide, write atomically.
36. Are Lua scripts atomic?
Yes. EVAL runs a Lua script atomically - no other commands run during it. Used for complex compare-and-set, multi-key updates, or atomic counters. Don't write long-running scripts; they block everyone.
37. What's the slowlog and how do you use it?
A list of commands that exceeded a latency threshold. SLOWLOG GET 10 shows the 10 slowest. Critical for finding the offending command when latency spikes - usually a KEYS, a giant SMEMBERS, or a script with a runaway loop.
38. What's MONITOR and when should you use it?
Streams every command running on the server in real time. Useful for debugging in dev. Never use in production - the volume crushes the server.
39. How do you debug "Redis is slow"?
(1) Check INFO commandstats for high-call-count or high-latency commands. (2) SLOWLOG. (3) Check memory usage and eviction rate. (4) Check network/CPU on the host. (5) Profile keys with redis-cli --bigkeys and --memkeys. (6) Look at client patterns - are you doing one round-trip per item?
40. What is redis-cli --bigkeys?
Scans the keyspace and reports the largest key per data type. The big offenders: a list with 10M items, a set with all your user IDs. Big keys are slow to operate on and dangerous in Cluster (can't migrate slots cleanly).
Patterns and Real-World Use (41-50)
41. How do you implement a distributed lock with Redis?
SET lock_key unique_value NX PX 30000 - set if not exists, with 30s expiry, unique value to identify the holder. Release by Lua-checking the value before deleting. For multi-node correctness, use Redlock - though Martin Kleppmann famously argued Redlock is unsafe; for non-critical locks, single-node is fine.
42. Cache-aside vs write-through vs write-behind?
- Cache-aside (lazy loading) - app reads cache, on miss reads DB and writes cache. Default pattern.
- Write-through - app writes both cache and DB synchronously. Fresh cache, double the writes.
- Write-behind - writes go to cache, async write to DB. Lowest latency, durability risk.
43. How do you avoid the thundering herd on cache miss?
Several techniques. (1) Single-flight - one request fetches, others wait. (2) Probabilistic early expiration - refresh before TTL. (3) Stale-while-revalidate - serve stale, refresh in background. (4) Mutex around the fetch - first to grab the lock fetches, others read the result.
44. What's a cache stampede?
Many concurrent requests miss the same expired key, all hammer the DB simultaneously. Mitigation: locking, probabilistic refresh, or just longer TTLs with background refresh.
45. How do you implement rate limiting in Redis?
Token bucket: INCR rate_key, set expiry on first increment, reject if count > limit. For sliding window, use a sorted set with timestamps as scores - count entries within the window. Redis Cell module gives you CL.THROTTLE as a single command.
46. What's the right way to do session storage?
Hash per session: HSET session:abc user 42 created_at ..., EXPIRE session:abc 3600. Sliding TTL on each request - reset expiry on access. Tag sessions with the user for KEYS-free cleanup using indexes.
47. Pub/sub vs Streams - which do you use?
- Pub/sub - fire-and-forget, no buffering, no persistence. If subscribers are offline, they miss messages.
- Streams - persistent, consumer groups, replay. Real queue semantics.
For real event processing, Streams. Pub/sub is fine for ephemeral notifications.
48. How do you use Streams correctly?
XADD events * key value to append. Consumer groups (XGROUP CREATE) let multiple consumers split work. XREADGROUP reads and adds to pending list; XACK confirms. Without XACK, the message stays pending and gets reclaimed by another consumer if the original dies.
49. Bitmaps and HyperLogLog - when do you reach for them?
Bitmaps - when you need to count or check membership at scale. "Did user X log in today?" SETBIT logins:2026-04-29 user_id 1. HyperLogLog - approximate count of distinct items in O(1) memory. Used for "how many unique visitors today" without storing every ID.
50. What's the worst Redis bug you've seen?
The classic: someone calls KEYS * against a 10M-key production server. Single-threaded, blocks for 30 seconds, every other client times out, cascading failures across the app. Always use SCAN. Always alarm on slowlog. Always set max client connections. The footguns are well-known; new bugs are usually old bugs.
Final thoughts
Redis interviews in 2026 reward operational depth. Knowing the data structures is table stakes. Knowing why your p99 spiked, why your hit rate dropped, why one key is hot - that's senior-level signal.
If you can talk about cache stampedes, big keys, and the eviction policy you'd pick for each use case, you'll handle 90% of Redis questions. The other 10% are gotchas about Cluster.