Question 1

When does it make sense to switch to Valkey Cluster mode?

Accepted Answer

Two trigger conditions. (1) Working set exceeds single-node memory — a 256GB Valkey node is already at the high end of what's economically rational; beyond that, shard across multiple smaller nodes. (2) Sustained write throughput saturates one CPU core: Valkey executes commands single-threaded, so 100k+ sustained writes/sec on one primary is the practical ceiling. Below those thresholds, a single-primary deployment with read replicas (see /high-availability) is simpler to operate.

Question 2

How many shards do I actually need?

Accepted Answer

Start with the working-set-divided-by-target-node-memory floor. If working set is 480GB and you want 48GB nodes, that's a 10-shard minimum. Round up to a power-of-2-or-3 (12 shards is common) for slot-rebalancing math. Each shard adds ~16,384/N hash slots. Over-sharding hurts: 50+ shards multiplies operational surface area without proportional throughput. Most real clusters live at 6-24 shards.

Question 3

What is MOVED vs ASK redirection and why does my client need to handle them?

Accepted Answer

Hash slots can migrate between shards while the cluster is online (during resharding or failover). When a client lands on the wrong shard for a given key, Valkey replies with either MOVED (the slot has permanently moved to another shard — update your slot cache) or ASK (the slot is currently mid-migration — retry on the target shard for this request only, but don't update the cache). Valkey-aware clients handle this transparently; legacy plain-Redis clients without cluster support break here.

Question 4

How do replicas work in Cluster mode?

Accepted Answer

Each shard (master node) has 1+ replicas that follow it via the standard replication protocol. On master failure, the cluster gossip protocol detects the outage and the highest-priority replica promotes itself, taking over the master's hash slots. Replica placement matters: spread replicas across availability zones to survive an AZ outage, and use cluster-replica-validity-factor to prevent stale replicas from promoting.

Question 5

Can Valkey Cluster span multiple regions?

Accepted Answer

Yes, but with caveats. The cluster gossip protocol assumes low-latency intra-cluster communication (typically <5ms RTT). Cross-region clusters work for read-fan-out via cross-region replicas, but full primary-fan-out across regions is fragile under network partition. The production pattern is per-region clusters federated at the application layer, not one global cluster. CRDT-based active-active replication is a Valkey 8.x roadmap item.

Question 6

What's the typical operational pain in Cluster mode?

Accepted Answer

Three recurring ones. (1) Resharding without traffic disruption — slot migration is online but heavy traffic can starve the migration; we schedule it for off-peak. (2) Client slot-cache staleness after failover — clients that don't promptly refresh on MOVED bursts can trigger redirect storms. (3) Cluster bus port (typically command port + 10000) needs firewall openings between every node-pair, not just to the client subnet — a common production gotcha.

Valkey Cluster Services

What we operate in Valkey Cluster mode

Shard Sizing & Topology

Slot Rebalancing

Client-Side Cluster Awareness

Multi-Key Operations

Failure Mode Engineering

Cross-Region Federation

Cluster sizing — the numbers behind the recommendations

6 shards × 2 replicas

12 shards × 1 replica

24 shards × 3 replicas, multi-AZ

Cluster mode FAQ

Design or rescue your Valkey Cluster

Related Valkey Services