Spring Data Redis Cluster: key slots change multi-key operations

One key is not the whole cluster

A catalog cache that worked against standalone Redis may fail after clustering when a script or multi-key command touches product:47 and tenant:west:47 in different slots. The client can follow redirects for single-key operations, but that does not make cross-slot operations legal. Hash tags can deliberately colocate related keys, for example {tenant-west}:product:47 and {tenant-west}:price:47. Use that only when the operation truly needs same-slot execution; overloading one slot can create a hot shard.

Scan each shard with care

A raw KEYS command on one cluster node sees that node's keys, not the whole cluster. Spring's cluster connection exposes cluster-wide operations, but a broad scan still consumes work across nodes. Region-wide cache clearing deserves a measured plan. Do not use keyspace events as a global deletion log: cluster event subscriptions are node-local and can miss other shards.

Exercise a real cluster

Run a two-key operation with keys in distinct slots and assert a clean failure. Repeat with keys sharing a hash tag. During resharding, measure redirection count and latency. A standalone Redis integration test cannot prove slot behavior, so the code below documents a key rule rather than claiming an executed cluster test.

Implementation sketch

String stockKey = "{tenant-west}:stock:47";
String priceKey = "{tenant-west}:price:47";
// The shared hash tag places these keys in one cluster slot.
// Keep unrelated tenants on different tags.

Cost and verification

Same-slot multi-key work is possible, but concentrating too many keys on one tag limits shard distribution. Cluster-wide scans grow with the total keyspace and node count.

Common Mistakes

• Do not assume a multi-key command works because both single-key reads work.
• Do not treat a one-node KEYS result as a full-cluster inventory.
• Do not rely on keyspace events for complete cluster-wide change delivery.

Read next

Spring Redis cache key schema: tenant, prefix and rollout version, Spring Redis cache writer: compound operations and replica stampedes, Spring Redis cache outage: choose failure behavior per operation, Spring Session Redis across replicas: shared login state has a Redis failure boundary.