Mastering Redis Scaling: Sentinel vs. Cluster Explained

So, you’ve unlocked the power of Redis as a cache, database, and message queue (if not, check out my previous article! 👉 Unlocking the Power of Redis). But what happens when a single Redis instance isn’t enough?

Maybe your application is growing, or you need high availability, or you’re tired of losing data every time a node crashes. Whatever the reason, it’s time to scale Redis. But how? What are some official ways provided by Redis?

Let’s break it down! 🚀

Scaling Redis – What Are Your Options?

Redis starts off simple – one master, one instance, everything’s great. But as your app grows, you might run into problems like:

🔄 Failovers – What if the master crashes?
🚀 High availability – Can Redis automatically switch to a new master?
📈 Scaling reads & writes – Can Redis handle millions of requests?

To solve these, you have three major ways to scale Redis:

Simple Master-Slave – A basic setup where one master handles writes, and one or more slaves replicate data for read scaling. But no automatic failover or write scalability.
Redis Sentinel – Great for high availability & failover, but still a single-writer setup.
Redis Cluster – Designed for horizontal scaling (sharding), allowing multiple nodes to handle writes.

Let’s dive into each! 🔎

Setting Up a Simple Master-Slave Redis Architecture

Let’s start with a basic master-slave setup. This is the simplest way to improve availability and distribute read loads. In this setup:

Master – Handles all writes and can also serve reads.
Slaves – Replicate data from the master and handle read requests.

📌 Starting a Redis Master:

Simply start a Redis instance as a master by running:

# Start Redis as a master
redis-server --port 6379

📌 Setting up a Slave:

# Connect to the master
redis-server --port 6380 --slaveof 127.0.0.1 6379

Or, in redis.conf, set:

slaveof 127.0.0.1 6379

This setup allows read scaling, but if the master fails, manual intervention is needed to promote a new master. That’s where Redis Sentinel comes in !!

Redis Sentinel – High Availability Without Sharding

What is Redis Sentinel?

Redis Sentinel is like a watchdog 🐶 that monitors Redis instances. It ensures that if your master goes down, a new master is elected automatically without manual intervention.

Here’s how it works:

👀 Monitors Redis instances (master & slaves)
🔄 Detects failures and promotes a new master
📢 Notifies applications to use the new master

How to Set Up Redis Sentinel?

A typical setup includes:

1 Master (receives writes)
1+ Slaves (for read replicas & failover)
3+ Sentinel nodes (monitor and trigger failover)

🔧 Basic Sentinel Configuration (sentinel.conf):

sentinel monitor mymaster <master-ip> 6379 2
sentinel auth-pass mymaster YOUR_MASTER_PASSWORD
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1

Once a failover happens, Sentinel elects a new master from the slaves and updates the application.

Why Three Sentinel Nodes?

You might have noticed that we recommend three Sentinel nodes in the setup. But why three? 🤔

Quorum-Based Decision Making: Sentinels use a majority vote (quorum) to confirm a master failure before triggering a failover. If you have only two Sentinels, they may disagree, leading to indecision.
Avoiding Split-Brain Issues: With just one Sentinel, there’s no redundancy, and a false failure detection can cause unnecessary failovers. With three, at least two must agree before acting.
Ensuring Reliability: If one Sentinel goes down, the remaining two can still function correctly and make failover decisions.

For a robust production setup, always use at least three Sentinel nodes to ensure stable failover mechanisms. 🚀

How Do Sentinels Know They Belong to the Same Pool?

You might be thinking, What if I have 100 Sentinel nodes running for different applications? How do the Sentinels know they belong to the same group managing a specific Redis master?

The answer lies in the Sentinel configuration and gossip protocol.

Common "monitor" configuration
Every Sentinel monitoring a Redis master must have the same configuration line:
```
 sentinel monitor mymaster <master-ip> <master-port> <quorum>
```
If two Sentinels have different names for the same Redis master (mymaster vs. master1), they will NOT recognize each other.
Gossip Protocol for Discovery
Sentinels periodically exchange messages to discover other Sentinels monitoring the same master. They do this via Redis’ pub/sub mechanism on the __sentinel__:hello channel.
Sentinel ID Persistence
When Sentinels start up, they register themselves and recognize others using unique IDs. They keep track of known Sentinels, ensuring that they don’t mistakenly interact with Sentinels from another application.

This ensures that all Sentinels in the same pool collaborate effectively while ignoring Sentinels meant for different Redis setups.

🚨 Downside? Sentinel does not scale writes. It only provides failover.

But what if your application requires not just high availability, but also the ability to handle increased write loads? That’s where Redis Cluster comes in !!

Redis Cluster – Horizontal Scaling with Sharding

What is Redis Cluster?

Unlike Sentinel, Redis Cluster is designed for scaling out. Instead of a single master, Redis Cluster uses sharding to distribute data across multiple nodes. Instead of storing all the data in a single master (like in Sentinel setups), Each master handles a portion of the dataset. It divides the dataset into 16,384 hash slots and distributes them among different master nodes.

🚀 How does it work?

Redis uses the CRC16 hash function to calculate a number between 0-16383 for a given key. Uses hash slots to distribute keys across nodes.
Each master has replicas (for failover).
No single point of failure (as long as quorum is met).

How to Set Up Redis Cluster?

A typical Redis Cluster setup has:

3+ Masters (each handling a portion of data)
1+ Slaves per master (for failover)
No need for Sentinel! Cluster handles failover internally.

🔧 Create a 6-node Redis Cluster (3 masters, 3 slaves):

redis-cli --cluster create 192.168.1.1:6379 192.168.1.2:6380 \
 192.168.1.3:6381 192.168.1.4:6382 192.168.1.5:6383 192.168.1.6:6384 \
 --cluster-replicas 1

🔄 Failover? If a master fails, its slave is promoted automatically!

🚨 Downside? Redis supports transactions using MULTI and EXEC, where you can execute multiple commands atomically. However, in a clustered environment, all the keys involved in a transaction must be in the same hash slot. You can’t run multi-key transactions across different slots. We will later discuss in future blogs on how to handle this.

Is a Single Master in Redis Cluster the Same as Sentinel? 🤔

Not quite! While having one master in a Redis Cluster might look similar to a Sentinel setup, there are some key differences you should know:

🚨 Failover Handling:

In Sentinel, dedicated Sentinel nodes monitor the master and trigger failover when needed.
In Redis Cluster, failover is handled internally by the cluster itself—no separate Sentinel required!

📈 Scaling Potential:

Sentinel setups are great for high availability, but they don’t scale writes—you’ll always have a single writable master.
With Redis Cluster, even if you start with one master, you can later add more masters and shard your data across them!

⚙️ Setup Complexity:

Sentinel is straightforward to configure for high availability.
Redis Cluster, even with one master, requires setting up hash slots, making it a bit more complex upfront.

Can I Start with Sentinel and Later Migrate to Cluster?

Yes, but resharding will be required! ❌ Sentinel does not use hash slots, so moving to Redis Cluster later isn’t as simple as flipping a switch.

In a Sentinel setup, all your data resides on a single master, with replicas acting as backups. There’s no built-in mechanism to distribute data across multiple nodes.

Redis Cluster, on the other hand, uses hash slots to distribute keys automatically. If you later migrate from Sentinel to Cluster, your existing keys won’t be automatically assigned to the correct slots

⚠️ Resharding is required! While Redis provides tools like redis-cli --cluster reshard to assist, the process still involves:

Migrating keys across masters to fit the hash slot model.
Ensuring minimal downtime to avoid application disruptions.
Handling potential inconsistencies if the migration isn’t planned properly.

Redis Sentinel vs. Redis Cluster – Which One to Choose?

Feature	Redis Sentinel	Redis Cluster
High Availability	✅ Yes	✅ Yes
Automatic Failover	✅ Yes	✅ Yes
Scales Reads	✅ Yes (via replicas)	✅ Yes
Scales Writes	❌ No	✅ Yes
Sharding	❌ No	✅ Yes
Complexity	🟢 Easy	🔴 Complex

Final Thoughts: Scaling the Right Way 🚀

Both Redis Sentinel and Redis Cluster have their place. If you just need high availability, Sentinel is simple and effective. But if your workload demands write scalability, Redis Cluster is the way to go.

The key is understanding your application’s needs and choosing the right tool. So, what’s your Redis setup? Are you using Sentinel or Cluster? Let’s discuss in the comments! 😊👇

💡 Still have doubts about Redis Cluster? It’s a vast topic on its own—covering sharding, failover, resharding, and more. Stay tuned for a deep dive into Redis Cluster in a future post!

If you found this helpful, give it a like and share! Stay tuned for more deep dives into distributed systems. 🚀

Scaling Redis: Sentinel vs. Cluster – What You Need to Know!

Table of contents