15 Most Frequent Redis Interview Questions: Data Structures, Persistence, and Clustering Complete Coverage

Background

I've really stepped on landmines with Redis. At a startup, I had to figure out caching solutions on my own and caused several production incidents — one cache avalanche took the service down for half an hour. When preparing for big tech interviews later, I spent two weeks thoroughly reviewing Redis from data structures to clustering solutions and compiled these 15 most frequently asked questions. Honestly, Redis interview patterns are quite predictable — if you prepare well, you can answer most of them.

I. Data Structures (4 Questions)

1. Redis's 5 Basic Data Types and Their Underlying Implementations?

Exam Focus: Underlying data structure principles

String uses SDS (Simple Dynamic String) underneath, with len and free fields added compared to C strings, O(1) length retrieval, binary-safe, and supports dynamic expansion. List before v3.2 used ziplist+linkedlist, then unified to quicklist (ziplist+doubly linked list). Hash uses ziplist or hashtable, using ziplist to save memory when elements are few. Set uses intset or hashtable, using intset when all values are integers and the count is small. ZSet uses ziplist or skiplist+hashtable. Interviewers love to follow up: When does ziplist convert to other structures? Answer: when element count or individual element size exceeds thresholds.

2. What is a Skip List? Why Redis Uses Skip Lists Instead of Red-Black Trees?

Exam Focus: Sorted set underlying implementation

A skip list is a multi-level linked list structure that achieves O(logN) lookup, insertion, and deletion through random levels. Redis chose skip lists over red-black trees because: simpler implementation with better code readability; more convenient range queries since linked list structures naturally support sequential traversal; easier to modify in concurrent scenarios (though Redis is single-threaded). Each skip list node randomly generates 1-32 levels, with higher levels having lower probability. During my interview, I drew the skip list lookup process, and the interviewer said "very clear understanding."

3. What is a Ziplist?

Exam Focus: Memory optimization mechanism

Ziplist is a list structure stored in contiguous memory, designed to save memory. Each entry contains prevlen (previous node's length, for backward traversal) and encoding. Advantages: memory-compact and cache-friendly; disadvantage: cascade update problem — a length change in a middle node may require expanding prevlen fields in all subsequent nodes. Redis 7.0 replaced ziplist with listpack, solving the cascade update problem. Interviewers love asking about this detail.

4. What is Redis Stream?

Exam Focus: New data structure awareness

Stream is a data type introduced in Redis 5.0, similar to Kafka's message queue design. It supports consumer groups, message acknowledgment, and persistence — more reliable than Pub/Sub. Core concepts: message ID (timestamp+sequence), Consumer Group, Pending Entries List (PEL). Suitable for lightweight message queue scenarios without introducing Kafka or RabbitMQ. Note: Stream message accumulation affects memory, so set MAXLEN to limit it.

II. Persistence (3 Questions)

5. Differences Between RDB and AOF?

Exam Focus: Persistence solution comparison

RDB is a binary snapshot file generated by forking a child process, with fast recovery but potential data loss after the last snapshot. AOF is an append-only operation log that fsyncs every second by default, with higher data safety but larger file size and slower recovery. RDB is suitable for cold backups, AOF for hot backups. Interviewers often ask: If both RDB and AOF are enabled, which does Redis load on restart? Answer: AOF, because it has more complete data.

6. What is Hybrid Persistence?

Exam Focus: Persistence optimization solution

Introduced in Redis 4.0: during AOF rewrite, RDB-format data is written at the beginning of the AOF file, followed by incremental data in AOF format. This ensures both recovery speed (RDB part loads quickly) and data completeness (AOF part records increments). Enable with aof-use-rdb-preamble yes. Follow-up: What's the AOF rewrite process? Main process forks child process → child rewrites → main process writes new commands to AOF rewrite buffer simultaneously → after child completes, main appends buffer data to new AOF file → replaces old file.

7. How to Choose Persistence Strategy in Production?

Exam Focus: Practical operations experience

Pure caching scenarios can disable persistence for best performance; scenarios requiring data safety should use hybrid persistence; if extremely sensitive to data loss, use AOF+fsync every second. Key configuration suggestions: adjust RDB save strategy per business; choose everysec for AOF fsync (balancing performance and safety); enable hybrid persistence; regularly back up RDB files to remote storage. In production, our AOF file was so large that restart recovery was slow — after enabling hybrid persistence, recovery time dropped from 30 minutes to 2 minutes.

III. Clustering (3 Questions)

8. Redis Master-Slave Replication Principles?

Exam Focus: High availability infrastructure

Full replication: when a slave connects for the first time or has been disconnected too long, the master generates an RDB and sends it to the slave, with new commands during sending written to the replication buffer, then sends buffer commands after RDB transfer. Partial replication: when briefly disconnected, the master maintains a repl_backlog circular buffer, and the slave requests incremental data with its offset. Key parameter: repl-backlog-size defaults to 1MB, recommended to increase to 256MB+ to avoid frequent full replications. Follow-up: How to handle master-slave delay? Read-write splitting may read stale data from slaves; critical business can force reads from master.

9. Sentinel Mode Principles?

Exam Focus: Automatic failover

Sentinel clusters monitor Redis master-slave nodes and determine if the master is down through heartbeat checks. Subjective down: a single sentinel thinks the master is unavailable; objective down: more than half of sentinels think the master is unavailable. Failover process: elect leader sentinel → select new master (priority > replication offset > smallest runid) → notify slaves to replicate from new master → notify clients of new master address. Interviewers love to ask: How do sentinels discover each other? Through the master's pub/sub channel __sentinel__:hello.

10. Redis Cluster Sharding Principles?

Exam Focus: Distributed architecture

Redis Cluster has 16,384 hash slots, with each master node responsible for a portion. Key slot is calculated via CRC16(key) % 16384. If a key isn't on the current node, a MOVED redirect is returned. The cluster needs at least 6 nodes (3 masters + 3 slaves) for high availability. Common issues: cluster doesn't support multi-key operations (unless keys are in the same slot, solvable with hash tags); scaling requires manual slot migration. Follow-up: Why 16,384 slots? Because heartbeat packets between nodes need to carry slot information — 16,384 slots can be represented in 2KB, and more slots would increase network overhead.

IV. Applications (3 Questions)

11. What are Cache Penetration, Breakdown, and Avalanche? How to Solve?

Exam Focus: Common caching problems

Penetration: querying non-existent data that's in neither cache nor database, requests go straight to the database. Solutions: Bloom filter, cache empty values. Breakdown: when a hot key expires, massive requests hit the database. Solutions: mutex lock, hot key never expires. Avalanche: when many keys expire simultaneously or Redis goes down, all requests hit the database. Solutions: add random values to expiration times, Redis cluster high availability, rate limiting and degradation. The production incident I encountered was an avalanche — many keys expired at the same time. Adding random offsets to expiration times solved it.

12. How to Implement Redis Distributed Locks?

Exam Focus: Distributed lock solutions

Basic approach: SET key value NX EX seconds, NX ensures mutual exclusion, EX sets expiration to prevent deadlocks. When releasing, use Lua scripts for atomicity (check if value matches before deleting). Redlock algorithm: acquire locks on multiple independent Redis instances simultaneously, succeeding on more than half means lock acquired. Production recommendation: use the Redisson framework, which encapsulates a watchdog mechanism for automatic renewal, solving the problem of locks expiring before business completes. Follow-up: Is Redlock always safe? Martin Kleppmann published an article questioning it, arguing it's unsafe in clock jump scenarios. Understanding this controversy is sufficient.

13. How to Use Redis as a Message Queue?

Exam Focus: Message queue solutions

Three approaches: List+LPUSH/BRPOP for simple queues, supports blocking but not consumer groups; Pub/Sub supports multiple consumers but no persistence, lost messages can't be recovered; Stream supports consumer groups, message acknowledgment, and persistence — the recommended approach for Redis 5.0+. Selection advice: use List for simple scenarios, Pub/Sub for publish-subscribe, Stream for reliable messaging. But Redis as a message queue is only suitable for lightweight scenarios — for heavy loads, use Kafka or RabbitMQ.

V. Others (2 Questions)

14. What Memory Eviction Policies Are Available?

Exam Focus: Memory management mechanism

8 policies: noeviction (default, reject writes without eviction); allkeys-lru (evict least recently used from all keys); volatile-lru (evict LRU from expiring keys); allkeys-lfu (evict least frequently used from all keys, Redis 4.0+); volatile-lfu (evict LFU from expiring keys); allkeys-random (random eviction from all keys); volatile-random (random eviction from expiring keys); volatile-ttl (evict keys with shortest TTL). Production recommendation: allkeys-lru or allkeys-lfu. LFU is better than LRU because it considers access frequency, not just recency.

15. What is the Expiration Deletion Mechanism?

Exam Focus: Key expiration handling

Redis uses a dual strategy of lazy deletion + periodic deletion. Lazy deletion: check if a key has expired only when accessed, deleting if expired. Periodic deletion: every 100ms, randomly sample a batch of keys with expiration times, delete expired ones, and continue checking if more than 25% are expired. This combination balances CPU and memory — using only lazy deletion wastes memory for long-unaccessed expired keys; using only periodic deletion with full scans is too CPU-intensive. Follow-up: What happens when many keys expire simultaneously? Periodic deletion runs multiple rounds, potentially affecting normal request response times.

Key Takeaways

The key to Redis interview preparation: understand underlying implementations of data structures, not just the "5 types" surface level; answer persistence and clustering questions with practical operations experience, ideally sharing pitfalls you've encountered; caching problems (penetration/breakdown/avalanche) are must-know questions where solutions should roll off your tongue. Also, Redis 7.0 features (Functions replacing Lua scripts, listpack replacing ziplist, multi-AOF files) are worth knowing to demonstrate your awareness of cutting-edge technology.

FAQ

Q: Do I need to understand Redis source code for interviews?
No need to go deep into source code, but understanding key data structure implementations (like SDS, skip lists, ziplist) is a big plus.

Q: Why is single-threaded Redis so fast?
Pure in-memory operations, IO multiplexing, avoiding context switching and lock contention. Note: Redis 6.0 introduced multi-threading for network IO, but command execution remains single-threaded.

Q: How to monitor Redis in production?
Focus on: memory usage, hit rate, connection count, slow queries, master-slave delay. Use Redis Exporter+Prometheus+Grafana for monitoring.