Redis Interview Q&A: Thread Model, Persistence, High Availability, and Cluster Mechanisms

The piece simulates an interview about Redis, walking through common interview questions on its architecture, persistence, high availability, and clustering.

Redis used a single‑threaded event‑driven model before version 4.0; starting with 4.0 it introduced optional multithreading for asynchronous delete commands such as unlink key , flushdb async , and flushall async .

The single‑threaded design is chosen for simplicity, eliminating lock contention, leveraging fast in‑memory data structures (hash tables, skip lists), and using I/O multiplexing to handle many client sockets efficiently.

Data durability is achieved through three persistence mechanisms: Append‑Only File (AOF) which logs every write command, RDB snapshots that periodically dump the in‑memory state to a binary file, and a hybrid approach (added in 4.0) that combines both.

AOF records commands and replays them on recovery, while RDB stores a point‑in‑time snapshot that can be loaded quickly; each has trade‑offs in speed and data‑loss risk.

The “write‑after‑log” strategy of AOF can lead to two risks: possible data loss if a crash occurs before the log is flushed, and the log‑writing operation may block the main thread, affecting latency.

Redis provides two snapshot commands: save , which blocks the client while writing the RDB file, and bgsave , which forks a child process to write the snapshot, allowing the main thread to continue handling writes.

High availability is realized via three patterns: master‑slave replication, Sentinel mode for automatic failover monitoring, and Redis Cluster for sharding and scaling.

Redis Cluster selects a node using a consistent‑hashing algorithm: the key is hashed with CRC16, the 16‑bit result is modulo 16384 to obtain a slot number, and each master node is responsible for a range of slots. An example allocation is shown in the table below.

Node

Slot Range

A

0‑5000

B

5001‑10000

C

10001‑16383

Overall, the interview covers why Redis’s design choices yield high performance, how it ensures data safety, and how it scales and remains available in production environments.