Redis — Replication, Sentinel & Cluster
How a single Redis instance becomes a resilient, horizontally-scaled system — leader-follower replication for copies, Sentinel for automatic failover, and Cluster's hash-slot model for sharding.
Learning objectives
- Explain Redis's leader-follower replication model and the staleness risk asynchronous replication introduces.
- Explain why Sentinel requires quorum and why production deployments run at least three Sentinel processes.
- Explain Redis Cluster's hash-slot model and why 16,384 slots enables resharding without a full remap.
- Choose between a single primary, Sentinel, and Cluster for a given scale and availability requirement.
Redis replication is a concrete instance of the leader-follower topology (NoSQL Foundations, Chapter 2 §2.1) rather than a different idea: one primary node accepts all writes, and any number of replicas connect to it, receive an initial full copy of the dataset (an RDB transfer, Chapter 02), and then stay in sync by replaying the primary's stream of write commands as they happen. Replicas serve reads by default and reject writes outright unless explicitly reconfigured — this is what makes "scale reads by adding replicas" a genuine, common Redis pattern.
Replication is asynchronous by default: the primary acknowledges a write to the client the instant it's applied locally, without waiting for any replica to confirm it received the change. This is fast, but it means a write your application believes succeeded may not exist on any replica yet — reading from a replica immediately after writing to the primary can return stale (pre-write) data, and if the primary fails in that same narrow window, that write can be lost entirely even though the client was told it succeeded. The WAIT command lets you require a write to be acknowledged by at least N replicas before it's considered durable enough to proceed — the same latency-vs-durability trade Transaction Mastery's Durability chapter covers for synchronous_commit, just applied across nodes instead of within one.
▲ Common mistake
Writing to the primary and immediately reading the same key from a replica in the same request, expecting to see the write. This is a textbook read-your-writes problem under asynchronous replication — the fix is either reading from the primary for anything that must reflect a write you just made, or using WAIT when the write genuinely needs to be confirmed on replicas before moving on.
◆ The problem
A single primary with replicas gives you read scaling and a warm standby, but if the primary itself dies, something still has to notice, decide a replica should take over, promote it, and tell every other replica and every client about the new primary — and it has to do all of that correctly even when the very thing that's supposed to detect the failure might itself be having network trouble.
Sentinel is a separate Redis process, run as its own small cluster alongside the primary/replica set, whose only job is exactly that: monitoring the primary and replicas, detecting when the primary is genuinely down (not just unreachable from one Sentinel's perspective), and orchestrating the failover — promoting the best-positioned replica to primary, reconfiguring the remaining replicas to follow it, and notifying clients of the new topology.
"Genuinely down" is the key phrase, and it's why Sentinel requires a quorum — a minimum number of Sentinels that must independently agree the primary is unreachable before any failover is triggered — and why production Sentinel deployments run at least three Sentinel processes, typically one per availability zone. This is the same majority-quorum principle NoSQL Foundations, Chapter 2 §2.3 covers for preventing split-brain: with only one or two Sentinels, a single Sentinel's own network hiccup (not the primary's) could trigger a false failover, and with only two, no majority is even possible if they disagree — three is the minimum that lets a majority genuinely outvote a single Sentinel having a bad network day.
Sentinel solves availability for a dataset that fits on one primary node's memory. Once the dataset itself is too large for a single node, or write throughput needs to be spread across more than one node, that's a partitioning problem (NoSQL Foundations, Chapter 2 §2.2) — and Redis's answer is Redis Cluster.
Redis Cluster splits the entire keyspace into 16,384 fixed hash slots. Every key is mapped to exactly one slot via CRC16(key) mod 16384, and each slot is owned by exactly one master node in the cluster (which can itself have replicas for HA, layering Sentinel-style failover per-shard). A client can ask any node which node owns a given key's slot and get redirected accordingly.
◆ Under the hood — why 16,384, specifically
The number is a deliberate engineering trade-off, not an arbitrary constant. Cluster nodes gossip slot-ownership information to each other continuously, and that ownership is represented as a bitmap — one bit per slot, so 16,384 slots means a 2KB bitmap per node, small enough to exchange cheaply and often even across a cluster with hundreds of nodes. Just as importantly, ownership is tracked per slot, not per key and not as a raw hash-range boundary — so resharding means moving specific slots (and only the keys currently mapped to them) from one node to another, a bounded, incremental operation you can run live, rather than recomputing a global range remap the way a naive fixed hash-partitioning scheme would need whenever a node joins or leaves (NoSQL Foundations, Chapter 2 §2.2's hotspot/hash-partitioning trade-off).
One practical wrinkle: multi-key operations (a transaction, a Lua script touching more than one key — Chapter 05) only work if every key involved maps to the same slot, since Cluster commands are routed per-slot. Hash tags — wrapping the part of the key you want hashed in {} — let you force related keys into the same slot deliberately: user:{42}:profile and user:{42}:sessions both hash only on 42, landing on the same slot even though the full key strings differ.
💻 Code example
-- without a hash tag: these two keys can land on different slots SET user:42:profile "..." SET user:42:sessions "..." -- with a hash tag: both keys hash on just "42", guaranteed same slot SET user:{42}:profile "..." SET user:{42}:sessions "..."
| Topology | Gives you | Doesn't give you | Choose when |
|---|---|---|---|
| Single primary + replicas | Read scaling, a warm standby | Automatic failover — someone has to promote a replica manually | Dev/test, or a managed offering that handles failover for you underneath |
| Primary + replicas + Sentinel | Automatic failover on top of the above | Sharding — the whole dataset still lives on one primary's memory | Dataset fits comfortably on one node; availability matters more than horizontal scale |
| Redis Cluster | Sharding across many nodes, each shard independently failover-capable | Simplicity — multi-key operations must respect slot boundaries (hash tags) | Dataset or write throughput exceeds what one node can hold or handle |
The deciding question is almost always "do I need to scale past one node's RAM and write capacity, or do I just need this single-node dataset to survive a node dying?" — the former is Cluster, the latter is Sentinel. It's also worth knowing that many managed Redis offerings (most major cloud providers' managed Redis products) implement primary/replica failover internally without exposing Sentinel to you directly — the concept above is still exactly what's happening underneath, which is why understanding it matters even if you never run redis-sentinel yourself.
Want a visual for this concept?
Generate a diagram tailored to “Redis — Replication, Sentinel & Cluster” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →