5 Redis Deployment Patterns Every Engineer Should Know

This article shares five Redis deployment patterns based on the author’s career experience.

1. Single Instance

The simplest deployment runs Redis on a single server and a single process. It is easy to deploy, configure, and maintain, but suffers from a single point of failure and memory limits tied to the host.

2. Master‑Slave + Sentinel

This high‑availability setup uses master‑slave replication combined with a Sentinel cluster for automatic health monitoring, failover, and read/write separation. It eliminates single‑point failures and improves system stability.

Master handles all write requests.

Slaves sync data in real time and can serve reads.

Sentinel monitors node health.

On master failure, Sentinel elects a new master.

3. Sharded Cluster + Consistent Hash

When cache data grows large, a single master‑slave‑sentinel setup becomes a bottleneck. Using consistent hashing, the key space (0‑2^32‑1) is organized into a ring, each Redis node is assigned multiple virtual nodes, and keys are routed to the nearest node clockwise.

Each shard operates in a master‑slave mode.

Sentinel clusters monitor and auto‑switch masters.

4. Sharded Cluster + Pre‑allocation

To smooth data migration when adding new shards, slots are pre‑allocated. The key space [0‑1023] is divided into equal ranges (e.g., four segments). A hash of the key modulo 1024 determines the slot, which maps to a specific shard.

5. Official Redis Cluster

Redis Cluster provides a fully decentralized, multi‑master‑multi‑slave architecture. Data is split into 16,384 slots, each node managing a subset. Nodes discover each other via the Gossip protocol, enabling automatic failover without Sentinel. Clients use CRC16 to hash keys to slots, and SDKs handle routing and node changes transparently.

Decentralized, multi‑master‑multi‑slave design.

Each partition consists of one master and multiple replicas.

Gossip protocol for health detection and automatic failover.

16384 hash slots distributed across nodes.

Clients route requests based on CRC16 hash of keys.

SDKs abstract slot management and node topology.

Redis Cluster offers high availability, sharding, and load balancing, suitable for large‑scale, high‑performance scenarios, though configuration and operation are more complex and some multi‑key operations have limitations.

6. No Silver Bullet

Each deployment mode has its own trade‑offs; there is no one‑size‑fits‑all solution. Selecting the appropriate pattern requires understanding business requirements and balancing performance, scalability, and operational cost.