Fix: CROSSSLOT Keys in request don't hash to the same slot

This error means you sent a multi-key command to Redis Cluster where the keys do not all map to the same hash slot. Redis Cluster splits the keyspace into 16384 slots distributed across nodes, and a command that touches several keys at once (MGET, MSET, SUNIONSTORE, a MULTI transaction, or a Lua script with multiple KEYS) can only run if every key lives in the same slot. When the keys hash to different slots, the cluster cannot execute the command atomically on one node and returns CROSSSLOT. This never occurs on a single node Redis, only on a cluster.

(error) CROSSSLOT Keys in request don't hash to the same slot

What this error means

Redis Cluster assigns each key to one of 16384 slots by hashing the key name, and each node owns a range of slots. Multi-key operations are atomic and node local, so all their keys must resolve to a single slot. By default the whole key name is hashed, so user:123:profile and user:123:cart almost certainly land in different slots and cannot be fetched together. The fix is to influence which slot a key hashes to, using hash tags, so the keys you need to operate on together share a slot. Where that is not appropriate, you restructure the code to stop issuing cross-slot multi-key commands.

Common causes

• MGET or MSET over keys that were not designed to share a slot.
• MULTI/EXEC transactions spanning keys in different slots.
• Lua scripts (EVAL) that pass multiple KEYS mapping to different slots.
• Set and sorted set operations like SUNIONSTORE, ZUNIONSTORE, or SINTERSTORE across keys in different slots.
• Code that worked on a single node Redis and broke after migrating to Redis Cluster.
• Hash tags applied inconsistently, so only some of the related keys carry the tag.

How to fix it

STABILIZE first. If a broken multi-key call is failing in production, the quickest safe change is to stop issuing it as one cross-slot command and instead touch the keys individually while you redesign the key names.

1. STABILIZE: replace the failing multi-key command with per key commands so the operation succeeds immediately, accepting the loss of atomicity for now.

GET user:123:profile
GET user:123:cart

This works because each command targets one key and one slot, unlike a single MGET across both.

2. DIAGNOSE: confirm the keys really are in different slots.

CLUSTER KEYSLOT user:123:profile
CLUSTER KEYSLOT user:123:cart

Different numbers confirm the cross-slot problem.

3. FIX with hash tags: rename related keys so they carry a common tag in braces. Only the substring between the first { and the next } is hashed, so both keys land in the same slot.

CLUSTER KEYSLOT user:{123}:profile
CLUSTER KEYSLOT user:{123}:cart

These now return the same slot number, so MGET user:{123}:profile user:{123}:cart succeeds.

4. FIX the writes so new keys use the tag from the start, and migrate existing keys to the tagged names. A rename within the same tag keeps the slot stable:

SET user:{123}:profile "..."
SET user:{123}:cart "..."

For existing data, copy to the new tagged key and delete the old one, since RENAME across different slots is itself rejected.

5. FIX by restructure where grouping is wrong: if the keys genuinely belong to different entities and should not share a slot, stop using multi-key atomic ops on them. Split into separate commands, or use a pipeline, which sends many single-key commands efficiently without requiring a shared slot.

6. Verify the multi-key command now runs against the cluster.

MGET user:{123}:profile user:{123}:cart

How to prevent it

• Design key names with hash tags from the start whenever keys will be read or written together atomically.
• Choose tag granularity that groups related keys (per user, per tenant) without forcing large fractions of the keyspace onto one slot.
• Audit code for MGET, MSET, transactions, and multi-KEYS Lua scripts before moving from single node to cluster.
• Prefer pipelines over multi-key atomic commands when you only need throughput, not atomicity, across unrelated keys.
• Watch slot and node balance so hash tags do not create hot slots that overload one node.

When to call a senior engineer

Call for help when migrating a single node Redis app to a cluster surfaces CROSSSLOT errors across the codebase, when hash tags are creating hot slots that unbalance the cluster, or when you need atomicity across keys that resist grouping into one slot. A senior engineer can redesign your key schema, rebalance the cluster, and rework the operations that assume everything lives on one node. Erzon can plan and execute a Redis Cluster key design that keeps multi-key operations correct without creating hotspots.