Deploy Redis Cluster With Explicit Slot, Failover, and Write-Loss Assumptions

A Java service migrates from one Redis node to Redis Cluster. Ordinary GETs work, but a transaction across two account keys fails with CROSSSLOT and a partition test reveals that an acknowledged cache write is not guaranteed to survive failover.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: design Redis Cluster keys, multi-key operations, client redirections, replica failover, persistence, and recovery tests around documented consistency limits.

What the symptom narrows down

• Related multi-key operations use keys that map to different hash slots.
• The client does not refresh its slot map or correctly handle MOVED and ASK during resharding.
• Asynchronous replication and a minority partition create a window in which acknowledged writes can be lost.

The branches are ordered to protect the strongest evidence around this possibility: related multi-key operations use keys that map to different hash slots. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Distributed storage trades one machine’s limits for routing, replication, failover, and consistency decisions; a healthy cluster can still return stale data, scatter a query, or lose an acknowledged write within a documented failure window; in this guide, the practical goal is to design Redis Cluster keys, multi-key operations, client redirections, replica failover, persistence, and recovery tests around documented consistency limits.

Evidence to collect before the fix

1. Inventory multi-key commands, scripts, transactions, and key naming before migration.
2. Use CLUSTER KEYSLOT to verify hash tags and inspect CLUSTER SHARDS plus per-node slot ownership.
3. Measure replication and persistence behavior under the exact durability settings, then state the acceptable data-loss window.
4. Test node failure, replica promotion, resharding, stale DNS or topology, and application reconnect behavior.

The sequence moves from observation toward intervention. Preserve the result of the final check—test node failure, replica promotion, resharding, stale DNS or topology, and application reconnect behavior—because it provides a useful comparison after the repair.

redis-cli -c CLUSTER KEYSLOT 'account:{42}:profile'
redis-cli -c CLUSTER KEYSLOT 'account:{42}:limits'
redis-cli -c MSET 'account:{42}:profile' '{}' \
                    'account:{42}:limits' '{"daily":100}'
redis-cli -c CLUSTER SHARDS

Apply fixes in the safest order

1. Co-locate only truly atomic related keys with a bounded hash tag such as an account identifier.
2. Use a maintained cluster-aware client that updates slot mappings and bounds redirects and retries.
3. Keep source-of-truth records outside a best-effort cache, or use documented acknowledgement mechanisms where their latency and limits fit.

Before applying “Co-locate only truly atomic related keys with a bounded hash tag such as an account identifier,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can run representative single-key and multi-key operations during controlled slot movement; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Prove recovery

• Run representative single-key and multi-key operations during controlled slot movement.
• Fail a primary and record availability, acknowledged-write outcome, topology refresh, and recovery time.
• Confirm large hash-tag groups do not create a new hot slot or make resharding disproportionately expensive.

One successful refresh is not closure. Keep the incident open until you can also fail a primary and record availability, acknowledged-write outcome, topology refresh, and recovery time, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

Record topology, versions, consistency settings, request or transaction identity, routing key, replication position, failure timeline, and recovery objective; test promotion and reconfiguration with production-shaped data before relying on them during an outage; include the result of this first observation: inventory multi-key commands, scripts, transactions, and key naming before migration.

State what was tested, including the result of “Inventory multi-key commands, scripts, transactions, and key naming before migration,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Shortcuts that create a second incident

• Do not describe Redis Cluster as consistent hashing; it uses 16,384 hash slots.
• Do not assume a successful SET is a durable cross-node transaction.

Primary references

• Redis Cluster specification — official reference consulted for this guide.
• Scale with Redis Cluster — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Co-locate only truly atomic related keys with a bounded hash tag such as an account identifier”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.