Redis Overview: Architecture, Master‑Slave Replication, Cluster Design, Persistence and Failure Handling

Redis is an in‑memory key‑value store that supports various data types such as strings, lists, sets, sorted sets and hashes, all with atomic operations and optional persistence strategies that synchronize data to disk or append‑only log files, enabling master‑slave replication.

In master‑slave mode a single master can have multiple slaves; writes go to the master while slaves serve read‑only traffic, reducing load on the master. Synchronization can be full (RDB file transfer) or partial, with the slave attempting partial sync first and falling back to a full sync using BGSAVE if needed.

Redis Cluster solves the single‑point‑of‑failure limitation of simple master‑slave setups by distributing data across multiple nodes using a hash‑slot mechanism (16,384 slots). Each node holds a subset of slots and communicates with all others via a gossip protocol, providing linear scalability, fault tolerance and eventual consistency.

Installation is straightforward: download the tarball from the official site, extract it, and for cluster mode ensure a Ruby build environment is present. A minimal cluster requires at least three master nodes.

Persistence is achieved through two mechanisms: snapshotting (RDB) where the server forks a child process to write a temporary file and then atomically replaces the old snapshot, and the Append‑Only File (AOF) where every write command is logged; AOF can be configured with appendfsync always, appendfsync everysec, or appendfsync no to balance durability and performance.

Replication works non‑blocking: the master continues to serve clients while a background save creates an RDB file that is sent to slaves, which load it into memory before receiving a stream of incremental commands. Slaves can also serve other slaves, forming a replication graph.

Consistent hashing is used in the cluster: each key is hashed with CRC16, the result modulo 16,384 determines its slot, and slots are evenly distributed among nodes, allowing easy addition or removal of nodes with minimal data movement.

Node failure detection relies on periodic PING messages; a node that does not reply within the timeout is marked PFAIL, and if a majority of masters agree, it becomes FAIL. Fail states are cleared when the node rejoins or after a configured grace period.

When a master fails, eligible slaves (those with the smallest node ID, up‑to‑date data, and belonging to the failed master) can be promoted to master after obtaining authorization from a majority of masters, followed by broadcasting PONG packets to update the cluster configuration.

The summary highlights that Redis Cluster offers high availability, fast access, automatic failover, and easy scaling, while drawbacks include potential data loss during asynchronous replication and limited support for password authentication in cluster mode.