Replication, Sentinel & Cluster
🔗 Replication, Sentinel & Cluster
mongodb2-5 and mongodb2-6 covered for MongoDB, achieved with Redis's own distinct tools.
Primary-Replica Replication
A replica continuously receives a stream of write commands from its primary, keeping an up-to-date copy — set up with REPLICAOF (the modern name; SLAVEOF is the older, still-functional alias).
Reads can be offloaded to replicas to spread load, the same idea as MongoDB's read preference — but Redis replication is asynchronous by default, meaning a replica can lag slightly behind the primary, the same replication-lag trade-off mongodb2-5 covered for MongoDB's secondaries.
Automatic Failover With Sentinel
Here's a genuine difference from MongoDB: plain Redis replication has no built-in automatic failover — if the primary goes down, replicas don't elect a new primary on their own the way a MongoDB replica set does. Sentinel is a separate process (typically run as a small cluster of its own, 3+ instances) that monitors the primary and its replicas, and when it detects the primary is genuinely down, promotes a replica to primary and reconfigures the others automatically.
Unlike MongoDB, where election logic is baked into the replica set itself, Redis deliberately separates "replicate the data" (plain replication) from "detect failure and promote automatically" (Sentinel) — an application connecting through Sentinel-aware clients can keep working through a failover without needing to know a promotion even happened.
Redis Cluster
Redis Cluster is Redis's sharding solution: the entire keyspace is divided into 16,384 hash slots, and each node in the cluster owns a subset of them. A key's slot is determined by hashing the key (CRC16) — a client that queries the wrong node gets redirected via a MOVED response to the node that actually owns that slot.
Sentinel vs. Cluster — Different Problems
Sentinel
High availability for one logical dataset — automatic failover if the primary dies, without splitting the data itself.
Cluster
Horizontal scaling — splits the dataset itself across many nodes, each owning a slice, similar in purpose to MongoDB's sharding (mongodb2-6).
These solve genuinely different problems and can even complement each other — Redis Cluster has its own built-in failure detection per shard, but a common point of confusion is assuming Sentinel and Cluster are two competing ways to do the same thing, when they're actually answering different questions ("is my one dataset still available?" vs. "can my dataset be bigger than one node?").
| Tool | Solves |
|---|---|
Plain replication (REPLICAOF) | Keeping copies of data in sync; read scaling |
| Sentinel | Automatic failover when the primary goes down |
| Cluster | Sharding the dataset itself across multiple nodes |
An operation touching multiple keys at once (a transaction, a Lua script, even a plain MSET across several keys) only works in Redis Cluster if every key involved hashes to the same slot — otherwise Redis refuses the operation, since the keys may live on entirely different nodes. The fix is a hash tag: wrapping the part of the key that should determine its slot in {}. user:{104}:profile and user:{104}:orders both hash only on 104, guaranteeing they land on the same node regardless of the rest of the key — the same deliberate design discipline mongodb2-6 required when choosing a good shard key, just expressed through key naming instead of an upfront schema decision.
💻 Coding Challenges
Challenge 1: Sentinel or Cluster?
A team has a dataset that comfortably fits on one Redis instance but needs to survive that instance failing without manual intervention. Which tool fits, and why isn't the other one relevant here?
Goal: Practice distinguishing the "stay available" problem from the "scale beyond one node" problem.
Challenge 2: Explain Redis's Failover Gap
Explain why plain Redis replication alone doesn't provide automatic failover the way a MongoDB replica set does, and what component fills that gap.
Goal: Practice articulating the specific architectural difference between Redis and MongoDB's approaches to high availability.
Challenge 3: Fix a Cross-Slot Operation
A Cluster deployment fails when running a multi-key operation on order:5001:items and order:5001:total together. Explain why, and rewrite the keys using a hash tag so the operation succeeds.
Goal: Practice applying the hash-tag fix to a concrete cross-slot failure.
🎯 What's Next
The final chapter is the Capstone: Building a Rate-Limited, Cached API — combining caching, rate limiting, pub/sub, and a Lua-scripted atomic operation into one small real application.