Redis Sentinel vs Redis Cluster: Choosing the Right HA Architecture

Redis Sentinel and Redis Cluster both provide high availability, but teams regularly choose the wrong one and pay for it with operational complexity they didn't need or with hitting undocumented scaling limits at the worst possible time. Here's the definitive guide to choosing between them.

Redis Sentinel Architecture

Sentinel provides monitoring, notification, and automatic failover for a Redis primary-replica setup. Three or more Sentinel processes form a quorum that monitors the primary. When the primary becomes unreachable, Sentinels elect a new primary from the replicas. Clients connect via Sentinel to discover the current primary address.

Sentinel Configuration

# sentinel.conf
port 26379
daemonize yes

# Monitor the primary (name, IP, port, quorum)
sentinel monitor mymaster redis-primary.internal 6379 2
sentinel auth-pass mymaster your_redis_password

# Failover triggers
sentinel down-after-milliseconds mymaster 5000   # declare primary down after 5s
sentinel failover-timeout mymaster 60000          # failover must complete in 60s
sentinel parallel-syncs mymaster 1                # replicas to sync simultaneously

Connecting to Sentinel from Python

from redis.sentinel import Sentinel

sentinel = Sentinel(
    [('sentinel1.internal', 26379),
     ('sentinel2.internal', 26379),
     ('sentinel3.internal', 26379)],
    socket_timeout=0.5,
    password='your_redis_password'
)

# Write always goes to primary
primary = sentinel.master_for('mymaster')
primary.set('user:42', json.dumps({'name': 'Alice'}))

# Read can go to replica (enable slave reads)
replica = sentinel.slave_for('mymaster', socket_timeout=0.5)
value = replica.get('user:42')

Redis Cluster Architecture

Redis Cluster shards keyspace across multiple primaries using consistent hashing (16,384 hash slots). Each primary owns a subset of slots and can have replicas. When a primary fails, one of its replicas is automatically promoted. Clients must use cluster-aware client libraries and handle MOVED and ASK redirections.

Setting Up Redis Cluster

# Create a 3-primary, 3-replica cluster (6 nodes minimum)
redis-cli --cluster create \
  redis1.internal:7001 redis2.internal:7002 redis3.internal:7003 \
  redis4.internal:7004 redis5.internal:7005 redis6.internal:7006 \
  --cluster-replicas 1 \
  -a your_redis_password

# Check cluster health
redis-cli -h redis1.internal -p 7001 -a your_redis_password \
  cluster info

# View slot distribution
redis-cli -h redis1.internal -p 7001 -a your_redis_password \
  cluster nodes

Cluster Client Pattern in Python

from redis.cluster import RedisCluster

rc = RedisCluster(
    host='redis1.internal', port=7001,
    password='your_redis_password',
    decode_responses=True
)

# Basic operations work identically to non-cluster
rc.set('user:42', json.dumps({'name': 'Alice'}))
value = rc.get('user:42')

# Multi-key operations ONLY work within the same slot
# Force same slot with hash tags:
rc.mset({'user:{42}:session': 'abc', 'user:{42}:cart': '[]'})
# Both keys hash to the same slot because {42} is the hash tag

Sentinel vs Cluster: Decision Guide

Working with JusDB on Redis HA

JusDB designs Redis high availability architectures — Sentinel for typical production deployments and Cluster for multi-terabyte workloads. We handle Sentinel configuration, Cluster setup and rebalancing, client library migration, and monitoring to ensure your Redis deployment survives primary failures without data loss.

Explore JusDB Redis Services →  |  Talk to a DBA

Related reading:

• Redis 8 vs Valkey 8
• Redis Streams vs Kafka