Which Redis high availability model fits your workload
If your dataset fits in one primary and you need automatic failover, a single primary with Sentinel is usually enough, and Redis Cluster is the choice only when data volume or throughput outgrows one primary. Sentinel monitors a primary and its replicas, promotes a replica when the primary fails, and gives clients the current master address. Choose Sentinel when the whole dataset lives on one primary, when your application runs multi-key operations, transactions or Lua scripts across arbitrary keys, and when you want a smaller operating surface. The Redis Sentinel documentation says a robust deployment needs at least three Sentinel instances placed on computers or virtual machines that fail independently, so confirm that those three hosts do not share a hypervisor, rack or availability zone before you rely on the design.
Choose Redis Cluster when one primary cannot hold the data or serve the request rate you need. Cluster shards keys across 16384 hash slots and needs at least three master nodes, and the Redis documentation strongly recommends six nodes, three masters and three replicas, for deployment. The cost is a constraint on your data model: a multi-key command, transaction or Lua script works only when all of its keys sit in the same hash slot. Hash tags can force related keys into one slot, but you must design key names for this before go-live, and you should audit existing code for multi-key calls that would fail across slots. Both options run on Redis Open Source and Valkey, so the decision is about topology and key design, not license. Because re-sharding and changing key layouts later are costly, treat this choice as hard to reverse and test it against your real access patterns first.
Sentinel and Cluster compared on scaling, multi-key limits and clients
This table compares Redis Sentinel and Redis Cluster factor by factor, from failover and data placement to minimum deployment, multi-key rules and client requirements. Read each row as the question to settle before choosing, since the two designs solve different availability and scaling problems.
| Factor | Redis Sentinel (single primary) | Redis Cluster (sharded) |
|---|---|---|
| Failover mechanism | Sentinel monitors the primary and replicas, then promotes a replica to master automatically | Nodes detect failed masters and promote a replica within the cluster, with no separate monitoring tier |
| Data placement | One primary holds the full dataset, and replicas copy it | Data is sharded across nodes using 16384 hash slots |
| Minimum deployment | At least three Sentinel instances on machines or VMs that fail independently | At least three master nodes, with a recommended six-node layout of three masters and three replicas |
| Multi-key operations | Commands can touch any keys because all data sits on one primary | Multi-key commands, transactions and Lua scripts work only when all keys share one hash slot; hash tags can force this |
| Scaling path | Scales reads through replicas, but the dataset must still fit on one primary | Adds capacity by spreading slots across more masters |
| Client support | Standard clients that understand Sentinel can find the current master address | Clients must be cluster-aware to route commands to the correct slot owner |
| License and versions | Redis Open Source 8.0 and later is available under AGPLv3, RSALv2 or SSPLv1 at your choice; Valkey is BSD-3-Clause with Valkey Sentinel | Valkey Cluster offers the same sharding model under BSD-3-Clause; confirm license choice for your Redis version with the Redis licenses page |
How Sentinel promotes a replica and tells clients where the primary is
Sentinel watches one primary and promotes one of its replicas when the primary stops answering. The Redis documentation describes four jobs: monitoring the primary and replicas, sending notifications, automatic failover that promotes a replica to master, and acting as a configuration provider that tells clients the current master address. Those jobs run in separate Sentinel processes, which agree on a failover among themselves before any replica is promoted. The consequence for you is that Sentinel protects a single write point. Your data still lives on one primary, so write throughput is capped by that one node no matter how many replicas you add.
The Redis Sentinel documentation says a robust deployment needs at least three Sentinel instances placed on computers or virtual machines that fail independently. The count matters because Sentinels vote, and a majority must agree that the primary is down before a failover starts. Three Sentinels on one hypervisor host give you three processes but only one failure domain, so a single host outage removes the primary and the quorum at once. Confirm with your platform team that each Sentinel sits on a different physical host, rack or availability zone, and that the cloud or hypervisor layer does not co-locate them.
Failover is not transparent to applications. Clients must ask Sentinel for the current master address, then reconnect after a promotion, so your client library must support Sentinel discovery and must handle dropped connections and retries. Writes sent to the old primary during the detection window can be lost, and the replication lag at the moment of failure determines how much data that is. Exact failover timing depends on your configured detection thresholds, network latency and client behavior, so measure it in your own environment with a forced primary outage before you commit. Ask your Redis or Valkey support provider, or your own test plan, to record time to detection, time to promotion and time until the application resumes writes.
What each topology is made of
Sentinel and Cluster solve the same availability problem in different ways, and the components you deploy differ accordingly. Read each layout for its minimum node count, what it adds beyond the data nodes, and where clients must understand the topology themselves.
Sentinel layout: primary, replicas and Sentinels
A Sentinel deployment is one primary, one or more replicas that copy its data, and a separate set of Sentinel processes that watch the primary and promote a replica when it fails. The Sentinels are the part teams most often underbuild. The Redis documentation calls for at least three Sentinel instances on machines or virtual machines that fail independently, so check that they do not share a host, rack or hypervisor with each other or with the primary.
Cluster layout: masters, replicas and bus
In Redis Cluster every node is a master or a replica of a master, and each master owns a subset of the 16384 hash slots. Nodes talk to each other over a cluster bus, which carries membership and failover traffic on a port separate from the client port. Confirm that your firewall and network policy allow the bus port between all nodes, because a cluster that cannot reach its bus will not fail over correctly.
Minimum three-master cluster
The documented minimum for a working cluster is three master nodes, each owning a share of the hash slots. This layout shards data, but a master that fails without a replica leaves its slots unavailable. Treat it as a starting point for testing or for workloads that can tolerate slot outages, not as a production baseline for a team that needs automatic recovery.
Recommended six-node layout
The Redis documentation strongly recommends six nodes: three masters and three replicas, so each master has a replica that can take over its slots. This doubles the node count and the memory footprint of the data set relative to a single copy. Budget for that capacity and for the operating work of monitoring twelve instances in a production topology, not six.
Client-side routing
With Sentinel, clients ask Sentinels for the current master address and reconnect after a failover, so the client library must support Sentinel discovery. With Cluster, clients must understand slot maps and follow redirects when keys move, and multi-key commands only work when all keys share one hash slot. Verify that your client library supports the topology you choose before you commit to it.
Choosing by dataset size, key design and team skills
Most caches, session stores and rate limiters hold one dataset that fits comfortably in the memory of one primary. For this shape, Sentinel usually fits: a single primary with replicas gives automatic failover without changing how the application addresses keys. Sentinel also keeps the data model unrestricted, so commands that touch many keys at once keep working as written.
- Failover without key changes: Sentinel promotes a replica and tells clients the current master address, so the keyspace stays a single namespace.
- Sentinel quorum: The Redis Sentinel documentation says a robust deployment needs at least three Sentinel instances on machines or virtual machines that fail independently. Placing all three on one hypervisor removes most of the benefit.
- Cluster is not needed for capacity alone: If the working set fits on one node with headroom for replication buffers, sharding adds operational work without a clear gain.
- Client support: Confirm that your client library supports Sentinel discovery before relying on it for failover.
- Failover is not zero data loss: Replication is asynchronous, so writes acknowledged by the old primary can be lost during a failover. Ask your team how much loss the session data can tolerate.
Before you commit, check the failover test results in your own environment, including how long clients take to reconnect after a promotion.
When the dataset or write rate exceeds what one primary can hold or serve, Redis Cluster is the model built for that job. It shards data automatically across nodes using 16384 hash slots, so capacity grows by adding masters rather than by enlarging a single machine. The price is that the application must be designed around slot ownership from the start.
- Minimum topology: The Redis Cluster documentation says a minimal working cluster needs at least three master nodes, and it strongly recommends six nodes with three masters and three replicas.
- Key design for single-key access: Keys should be accessed one at a time or with patterns that never span slots. Keys that the application reads together need consistent naming so they hash to the same slot.
- Hash tags: A hash tag such as a braced substring in the key name can force related keys into one slot. Overusing a single tag concentrates load on one master and undoes the sharding.
- Hot keys: A single very popular key still lives on one shard. Test read patterns against the slot map before assuming that sharding solves contention.
- Scaling work: Resharding moves slots between nodes. Ask the vendor or your platform team how resharding is rehearsed and monitored.
Before choosing Cluster, list the keys your application touches in one request and confirm that the key naming already supports slot-local access.
Applications that run transactions, multi-key commands or Lua scripts across several keys are the most constrained case for Redis Cluster. The Redis Cluster documentation says multi-key operations work only when every key in a command, transaction or Lua script belongs to the same hash slot. Sentinel does not impose that limit because all keys live on one primary. For this shape, Sentinel is often the simpler choice unless the data volume forces sharding.
- Same-slot rule: A MULTI block or script that touches keys in two slots fails under Cluster, so the rule must hold for every code path, not just the common one.
- Hash tags as a contract: If you rely on hash tags, document the tag scheme and enforce it in code review. A missed tag shows up as an error in production.
- Lua script design: Scripts must declare their keys so the cluster can route them. Scripts that build key names at runtime are hard to validate for slot placement.
- Migration cost: Refactoring keys after launch is expensive because stored data must move with the new names.
- Test coverage: Run the full command set against a Cluster test environment before any production decision.
Before committing to Cluster, ask the application team to list every multi-key command and script, then check each one against the same-slot rule.
Teams on Valkey have the same two high availability models, with the same constraints, because Valkey mirrors the Redis topology. Valkey Sentinel provides high availability when not using Valkey Cluster, with at least three Sentinel instances recommended, and Valkey Cluster uses the same cluster design. Existing Redis client libraries connect to Valkey without code changes, so the choice between Sentinel and Cluster is independent of the fork.
- Same key design rules: Hash slot and multi-key constraints carry over, so the review above applies unchanged.
- Version alignment: Valkey 9.1 is the current stable line according to the Valkey release page. Confirm which release line your team will standardize on across all nodes and Sentinels.
- Mixed fleets: Valkey reads and writes RDB and AOF files compatible with Redis OSS 7.2. If some nodes still run Redis 7.4 or later, the data files are not compatible, so do not mix them in one topology.
- Migration path: Valkey's migration guide documents four methods, including replication with REPLICAOF followed by promotion, and for clusters, adding Valkey nodes as replicas and promoting them with CLUSTER FAILOVER.
- Vendor support: Ask your managed or commercial provider which Valkey release lines and cluster features it supports.
Before you standardize, confirm the release line, the Sentinel count and the client library versions on every node, and test a failover in a non-production cluster.
What running each topology asks of your team
This table compares what Sentinel and Cluster ask of your team across upgrades, backups, monitoring, resharding and client changes. Read each row as a question to put to your engineers, and note that the Valkey migration methods are documented options for moving between engines, not a recommendation to move.
| Area | Redis Sentinel (single primary with replicas) | Redis Cluster (sharded primaries) |
|---|---|---|
| Upgrades | Upgrade replicas first, fail over to a promoted replica, then upgrade the old primary. Sentinel configuration must match the server version your team runs. | Rolling upgrades touch every shard. Confirm with your vendor how cluster nodes and slot ownership behave during mixed-version periods before scheduling. |
| Backups | Snapshot one dataset from a replica. Restore procedures are simple because all data lives in one keyspace. | Backups must cover every shard consistently. Ask your team how they will capture and restore each primary and its replicas together. |
| Monitoring | Watch the primary, replication lag, and Sentinel quorum health across at least three Sentinel instances. | Watch per-node health, slot coverage, and whether any shard has lost its primary. Alerts need to be per shard, not only per cluster. |
| Resharding and scaling | Scaling means a bigger primary or more read replicas. Write capacity stays bound to one primary. | Adding or moving hash slots between nodes is an operational task. Plan it as a change with testing, rollback and monitoring steps. |
| Client changes | Clients must ask Sentinel for the current master address. Confirm that your client library supports Sentinel discovery. | Clients must be cluster-aware to follow redirects. Multi-key commands only work when keys share a hash slot, so application code may need hash tags. |
| Moving between engines | Valkey documents RDB copy, REPLICAOF followed by promotion, and key-level MIGRATE as options. Confirm the Redis version first, since Redis 7.4 and later data files are not compatible with Valkey. | For clusters, the documented option is adding Valkey nodes as replicas and promoting them with CLUSTER FAILOVER. Test this path in a non-production environment before committing. |
How to move from Sentinel to Cluster without rewriting the application
This sequence shows whether an existing Sentinel deployment can move to Redis Cluster sharding with changes limited to key design, client configuration and topology, and it leaves a tested rollback path before any production traffic moves.
Confirm the reason for moving to sharding
The platform owner and the application lead agree in writing on the problem that Cluster would solve, such as dataset size that exceeds one primary's memory or write throughput that a single primary cannot absorb. Sentinel already provides automatic failover for one primary, so if the real need is only failover, the team should confirm that Sentinel still meets it before continuing. The step closes when the decision and its measured trigger are recorded in the change record, and the team has a current baseline of memory use and write load from its own monitoring.
Audit multi-key commands and scripts
The application team lists every command, transaction and Lua script that touches more than one key, including those hidden in libraries, background jobs and reporting tools. Redis Cluster only runs multi-key operations when all keys in the command, transaction or Lua script share one hash slot, so each case needs a classification: keys already co-located, keys that can be co-located by key design, or keys that must be separated and the operation rewritten. The step closes with an inventory that names every multi-key call site, its owner and its planned treatment. Engineers should confirm the inventory against query logs from their own environment, because code reviews often miss dynamically built keys.
Add hash tags where co-location is needed
For the multi-key calls that the audit marks as co-locatable, the team chooses hash tags, the braces convention that forces keys sharing the same tagged substring into one hash slot. The team should check that the tag values do not create a hot slot, since a popular tag concentrates traffic on one shard and cannot be spread by the cluster. Changes go through the application's key-builder layer so the code path stays the same for callers. The step closes when a test run confirms that each tagged set of keys maps to the same slot, using the cluster's key-slot reporting in a staging cluster, and that the hot-tag review is signed off by the data owner.
Test client cluster support in staging
The platform team confirms that every client library in the application's stack supports Redis Cluster, including redirect handling for moved and ask responses, topology refresh after failover and the connection pool behavior during resharding. Sentinel-aware client configuration is not interchangeable with cluster-aware configuration, so the team should check each library version against its own release notes and not rely on general claims. The step closes with a staging test run that exercises normal reads and writes, a primary failover and a resharding event, with results compared against the Sentinel baseline. Teams should confirm the client behavior in their own environment before relying on it.
Build the target topology and migrate data
The infrastructure team builds the target cluster with at least three primary nodes, and the Redis documentation strongly recommends six nodes with three primaries and three replicas for deployment. The team copies data from the Sentinel primary into the cluster using a method it has validated in staging, and it confirms that the migration method suits its Redis version, since the Valkey migration guide notes that Redis Community Edition 7.4 and later produce data files that Valkey cannot read and that method differences matter. The step closes when key counts, sampled values and memory use match between source and target, and the cluster reports all slots assigned and healthy.
Shift traffic in controlled stages
The application team moves a limited set of services or a percentage of traffic to the cluster endpoint while the Sentinel deployment keeps running and receiving writes in parallel or through a defined sync window, as the chosen method requires. Error rates, latency, redirect counts and memory per shard are watched at each stage against thresholds the team set before the change. The step closes when all traffic runs on the cluster for the agreed observation period and the on-call team signs off, and the decision to decommission Sentinel is recorded separately. Thresholds and observation periods must be set by the team, since no supplied fact provides them.
Plan and rehearse the rollback
Before the cutover, the team writes a rollback procedure that names the trigger conditions, the owner who can call it, the steps to point clients back to the Sentinel endpoint and the handling of writes made during the cluster period. Rollback is only credible if it has been rehearsed, so the team runs the procedure in staging and confirms that the Sentinel primary can take traffic again without data loss in the test scenario. The step closes with a signed rollback runbook and a rehearsal record. Teams should confirm with their Redis version and deployment tooling whether the Sentinel deployment can be kept intact through the cutover window.
Questions buyers ask before choosing a Redis topology
Can Redis Sentinel scale writes across nodes?
No. Sentinel provides high availability for a single primary: it monitors the master, notifies clients and promotes a replica when the master fails. All writes still go to one primary, so Sentinel does not add write capacity. Replicas can serve reads, which helps read-heavy workloads, but the write ceiling is the primary's. If write throughput or dataset size is the constraint, the question points toward Redis Cluster, which shards data across nodes using 16384 hash slots. Confirm the expected write rate and dataset size against your own load tests before choosing, because those numbers decide whether a single primary is enough.
Does Redis Cluster remove the need for hash tags?
Not entirely. Redis Cluster distributes keys automatically across slots, but multi-key operations, transactions and Lua scripts work only when all keys involved belong to the same hash slot. Hash tags are the mechanism that forces related keys into one slot, so applications that touch several keys together still need them. Without hash tags, you may need to redesign key naming or split operations in application code. Review every multi-key command, transaction and script in your codebase before adopting Cluster, since a missed case surfaces as an error in production rather than during planning.
What drives the cost of running Sentinel compared with Cluster?
The cost comes mostly from node count, operator time and application changes. A Sentinel deployment needs at least three Sentinel instances placed on machines or virtual machines that fail independently, plus a primary and its replicas. A minimal Redis Cluster needs at least three master nodes, and the documentation strongly recommends six nodes with three masters and three replicas. Cluster therefore carries more nodes and more operational procedures for resharding and failover. Application effort is the other driver: moving to Cluster may require key design work and client support checks. Ask any implementation partner for a written scope that lists node counts, failure-domain placement, client changes and testing, since those items set the one-time and recurring costs.
Can our team run a Redis topology without outside help?
It depends on your team's experience with distributed failure modes, not on the software alone. Sentinel is the simpler model: one primary, replicas and a quorum of Sentinels, with clients asking Sentinel for the current master address. Cluster adds slot ownership, resharding and multi-key constraints that your application and runbooks must respect. Teams that can already operate replicated databases and test failover on their own infrastructure may manage either model in-house. Teams without that practice often benefit from a fixed-scope engagement that covers deployment, failover testing, documentation and handover. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and the written scope defines what is included.
How long does a migration to Redis Cluster take, and what does it depend on?
The duration depends on the factors below, and no fixed figure applies to every environment. The main drivers are the number of multi-key operations that need redesign, the size of the dataset that must be resharded, the client libraries in use, and how much failover and load testing your change process requires. Migrating from a standalone or Sentinel setup to Cluster is a topology change on top of the data move, so it usually takes longer than a Sentinel-only deployment. Ask for a timeline in the written scope that names each dependency and the testing gates before cutover. Any duration you receive should be traced back to those drivers.
Does the license choice change the Redis topology decision?
The license changes which software you run, not how high availability works. Sentinel and Cluster are both available in Redis Open Source 8.0 and later, which you can use under AGPLv3, RSALv2 or SSPLv1 at your choice, and in Valkey, which is BSD-3-Clause. Valkey also ships Sentinel and cluster modes, with at least three Sentinel instances recommended. The license matters if you modify Redis and offer it as a network service, since the modified source must be made available to that service's users. Redis 7.4 and later produce data files that Valkey does not read, so the version you run affects migration effort. Have counsel review the license terms against your internal and hosted use before you commit to a topology.
Can Sentinel and Cluster be mixed in one deployment?
Sentinel and Cluster are alternative answers to the same availability question, so a single Redis keyspace uses one or the other. The Redis documentation describes Sentinel as the high availability option for setups that are not using Redis Cluster. A Cluster handles failover among its own masters and replicas, so Sentinel is not layered on top of it. Teams sometimes run separate Sentinel-managed instances for one workload and a Cluster for another, which keeps each workload's failure behavior easy to explain. Confirm this split with your architecture review, and document which keys and clients belong to each topology.
How DeployOpen scopes and delivers Redis high availability
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the Sentinel or Cluster decision is made against the client's own network, failure domains and application key patterns. Engagements are typically fixed-scope, with the topology and deliverables agreed in writing before work starts.
How we scope
- Confirm whether the application needs multi-key operations, transactions or Lua scripts that span keys, since these shape the Sentinel or Cluster choice.
- Record the required number of Sentinel or primary nodes and the failure domains where each must run independently.
- Agree in writing which Redis or Valkey version, license edition and client libraries are in scope before any build begins.
How we build
- Deploy a single primary with replicas and at least three Sentinel instances on separate machines or virtual machines, or a Cluster with at least three primaries.
- Test automatic failover and client reconnection behavior against the client's own libraries, including hash tag design where keys must share a slot.
- Configure and harden the deployment in the client's cloud accounts, data centers or air-gapped networks, with monitoring for failover events.
How we hand over
- Document the topology, failover runbooks, client connection settings and the steps to add a replica, shard or Sentinel later.
- Walk the client's operations and application teams through failover drills so they can run them without DeployOpen present.
- Deliver backup and restore procedures and a written record of what was tested, what was not, and what the client must confirm.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Plan version upgrades around the maintained release lines of the chosen engine, confirmed with the vendor before each change window.
- Revisit the topology when data growth, key patterns or client changes make the original Sentinel or Cluster choice no longer fit.
