EvalcueAIRedis interview questions
Redis Interview Questions for Backend Engineers
Redis interview questions become much more useful when tied to production caching and coordination problems. Prepare to explain data structures, eviction, persistence, replication, clustering, and what can go wrong under load.
Core Redis questions
Understand why Redis is fast, its major data structures, expiration behavior, and the difference between using it as a cache and using it as a durable data store.
Why is Redis fast?
Data lives in memory, commands run on a single main thread so there is no lock contention, network I/O is multiplexed through an event loop, and the data structures are compact. The network round trip usually costs more than the command.
Which Redis data structures would you use, and for what?
Strings for counters and cached values, hashes for objects, lists for simple queues, sets for membership checks, sorted sets for leaderboards and time-ordered data, and streams for durable event logs with consumer groups.
How does key expiration work?
Expired keys are removed lazily when someone accesses them, and actively by a background job that samples keys with a TTL. So memory from expired keys can linger briefly, and replicas wait for the primary to propagate deletions.
RDB or AOF persistence?
RDB writes periodic snapshots, which are compact and quick to restore but lose the writes since the last snapshot. AOF logs every write; with fsync every second you lose at most about a second of data, at the cost of larger files. Many setups enable both.
Caching interview questions
Caching questions usually move quickly to invalidation and what happens when things fail.
Cache-aside or write-through?
With cache-aside, the application reads the cache, falls back to the database on a miss, and fills the cache. With write-through, every write updates the cache and the database together. Cache-aside is simpler and more common; write-through keeps the cache fresher but caches data that may never be read.
What is a cache stampede and how do you prevent it?
When a hot key expires, many requests miss at once and all hit the database. Prevent it with a lock or single-flight so one request rebuilds the value, by serving stale data while refreshing, or by refreshing shortly before expiry.
How do you deal with hot keys and keys that expire together?
Add random jitter to TTLs so keys don't expire at the same moment. For one very hot key, keep a short-lived local copy in each app instance or replicate the key under several names to spread the reads.
What happens when Redis runs out of memory?
It follows maxmemory-policy. With noeviction, writes start failing. Cache workloads usually use allkeys-lru or allkeys-lfu so the least useful keys are evicted. Watch evicted_keys and memory fragmentation.
Scaling and distributed follow-ups
Prepare for replication, Sentinel, Cluster, pipelining, transactions or Lua for atomicity, distributed-lock caveats, and how the application behaves when Redis is slow or unavailable.
How do replication and failover work?
Replicas copy the primary asynchronously, so a failover can lose the most recent writes. Redis Sentinel watches the primary and promotes a replica when it fails; Redis Cluster does the same for each shard.
How does Redis Cluster split data?
Each key maps to one of 16,384 hash slots by CRC16, and the slots are spread across primaries. Multi-key commands only work when all keys share a slot, which you can force with hash tags such as {user:42}.
Pipelining, MULTI/EXEC, or a Lua script?
Pipelining batches commands to save round trips but gives no atomicity. MULTI/EXEC runs a queued batch atomically, with WATCH for optimistic locking. A Lua script runs atomically and can branch on values it reads, which makes it the usual choice for check-then-set logic such as a rate limiter.
What should the application do when Redis is slow or down?
Set tight timeouts, wrap calls in a circuit breaker, and fall back to the database with request coalescing so a cold cache doesn't flood it. Decide in advance which features can degrade and which must fail.
Common questions
Should Redis be the source of truth?
It depends on the use case, but for many application caches Redis is intentionally not the durable source of truth. Explain persistence, recovery, consistency, and what happens if Redis data is lost.
How do you prevent cache stampede?
Common techniques include locking or single-flight refresh, stale-while-revalidate, probabilistic early refresh, and adding TTL jitter so many hot keys do not expire simultaneously.