How Interviewers Probe Redis Knowledge
Redis interview questions rarely stop at 'what is Redis' — strong candidates are expected to reason about time complexity of specific commands, the durability tradeoffs of RDB vs AOF, how replication and failover actually work, and when Redis is the wrong tool. Interviewers often present a scenario ('design a leaderboard', 'design a rate limiter', 'why is this app OOMing') and evaluate whether you reach for the right data structure and configuration rather than reciting definitions.
Cricket analogy: Like a selector judging a batter not just on career average but on how they handle a moving ball under pressure, a good interviewer judges Redis knowledge by scenario reasoning (design a leaderboard) rather than rote definitions.
Data Structures and Complexity
Expect questions like: what's the time complexity of ZADD (O(log N) per element, due to the underlying skip list), why use a Hash instead of many top-level String keys for an object (memory efficiency via listpack encoding for small hashes, plus atomic HGETALL for the whole object), and when Sorted Sets beat Lists for a leaderboard (O(log N) ZADD/ZRANK vs O(N) scans). OBJECT ENCODING reveals which internal representation Redis chose (e.g., 'listpack' for a small Hash, 'skiplist' for a large Sorted Set), and interviewers may ask you to explain why Redis automatically switches encodings as a collection grows past its configured thresholds.
Cricket analogy: Like a fielding side switching from a spread field to a tight slip cordon once a batter starts edging more, Redis switches a Sorted Set's internal encoding from listpack to skiplist once it crosses a size threshold, trading memory for speed.
ZADD leaderboard 1500 "player:42"
ZADD leaderboard 2200 "player:7"
ZRANK leaderboard "player:42" # O(log N)
ZREVRANGE leaderboard 0 2 WITHSCORES # top 3 players
OBJECT ENCODING leaderboard # "listpack" or "skiplist" depending on sizePersistence and Durability Tradeoffs
A classic question: 'if the Redis process crashes, how much data can you lose, and why?' RDB snapshots (SAVE/BGSAVE, or automatic save points) are compact point-in-time dumps, so you can lose everything written since the last snapshot; AOF (Append Only File) logs every write command and, with appendfsync everysec (the default), you can lose at most about one second of writes, while appendfsync always fsyncs every write for near-zero loss at a steep latency cost. Many production deployments enable both: AOF for durability and periodic RDB for fast restarts and compact backups, and Redis 7's multi-part AOF makes rewrites and truncation safer than the old single-file format.
Cricket analogy: Like a scorer taking a full photo of the scoreboard only at drinks breaks versus a commentator writing down every single ball as it happens, RDB snapshots lose everything since the last save while AOF with everysec loses at most a second's worth of deliveries.
Replication, Eviction, and Scaling Questions
Expect questions on replication ('is Redis replication synchronous or asynchronous by default?' — asynchronous, meaning a failover can lose the last few writes that hadn't reached the replica), eviction policies ('what does maxmemory-policy allkeys-lru do versus noeviction?' — LRU evicts approximate least-recently-used keys across the whole keyspace once maxmemory is hit, while noeviction just rejects writes with an OOM error), and scaling ('how does Redis Cluster shard data?' — hash slots, 16384 of them, computed via CRC16 of the key, or the key's hash tag if one is present in braces). A weak answer treats Redis as 'just a cache'; a strong answer discusses it as a data structure server with configurable durability, replication, and clustering that happens to be excellent as a cache.
Cricket analogy: Like a stand-in scorer who updates the official scoreboard a few seconds after the real action, asynchronous Redis replication means a replica can lag the primary by a few writes, which can be lost on a sudden failover.
A common wrong answer in interviews is describing Redis as 'just a cache.' Redis is a full in-memory data structure server with optional durability (RDB/AOF), replication, Sentinel-based failover, and Cluster sharding — treating it as only a cache underestimates what interviewers expect you to know about its persistence and scaling model.
- Be ready to reason through scenario prompts (leaderboard, rate limiter, session store), not just recite command syntax.
- Know the Big-O of common commands: O(1) for GET/SET/HGET, O(log N) for ZADD/ZRANK, O(N) for KEYS and unbounded LRANGE.
- Explain RDB vs AOF durability tradeoffs and why many production setups use both together.
- Know that replication is asynchronous by default, so failover can lose the most recent unreplicated writes.
- Understand maxmemory-policy options (noeviction, allkeys-lru, volatile-ttl, etc.) and when each is appropriate.
- Explain Redis Cluster's 16384 hash slots and how CRC16(key) or hash tags determine slot placement.
- Avoid describing Redis as 'just a cache' — it's a data structure server with configurable durability and scaling.
Practice what you learned
1. What is the time complexity of ZADD on a Sorted Set?
2. By default, is Redis replication synchronous or asynchronous?
3. What does maxmemory-policy noeviction do?
4. How many hash slots does Redis Cluster divide the keyspace into?
5. What durability guarantee does appendfsync everysec provide?
Was this page helpful?
You May Also Like
Redis Streams
How Redis Streams model an append-only log, and how XADD, consumer groups, and trimming work together for durable event processing.
Redis Security Basics
Core practices for securing a Redis deployment: authentication, ACLs, TLS encryption, and network hardening.
Redis Quick Reference
A condensed cheat sheet of the most-used Redis commands across data types, key management, and server administration.