Redis Cluster Performance

Sharding considerations.

Overview

Redis Cluster sharding distributes keys across 16384 hash slots, with each slot owned by exactly one master node. The performance and operations of a Redis Cluster come down to two questions: are the keys distributed evenly across slots, and do operations that touch multiple keys land in the same slot. Get either wrong and you get hot shards, cross-slot errors, and operational pain that is hard to back out of after the data is in place.

• 16384 hash slots. Keys map to slots via CRC16 mod 16384; slots map to masters; resharding moves slots between masters.
• Key distribution. Random keys distribute evenly; structured keys (tenant prefix, customer ID) can concentrate on hot slots.
• Cross-slot operations. MULTI, transactions, and Lua scripts that touch multiple keys require all keys in the same slot or they error.
• Hash tags plus resharding. Curly-brace tags ({customer:42}:order, {customer:42}:profile) co-locate related keys in one slot; resharding rebalances slots without downtime when distribution drifts.

The approach

The practical approach is to design hash tags up front for any keys that need cross-key operations, monitor per-shard key distribution to catch hot shards before they hurt, plan resharding as a regular operation rather than an emergency, and document the sharding strategy so the next operator inherits the model. The cluster shape is fixed at design time; the cost of getting it wrong is paid at every operation thereafter.

• Hash tag design. Per-related-keys the hash tag inside curly braces; co-locates keys for transactions, scripts, and MULTI.
• Monitor key distribution. Per-shard key count and memory; redis-cli --cluster check; alert on imbalance before it becomes a hot shard.
• Plan resharding. Per-quarter rebalancing as routine ops; redis-cli --cluster reshard during low-traffic windows; not an emergency tool.
• Avoid cross-slot plus documented strategy. Schema design avoids cross-slot ops where possible; per-cluster sharding strategy documented for operational review.

Why this compounds

Redis Cluster discipline compounds across the cluster lifetime. Right sharding choices early prevent the painful reshape later; even key distribution survives node failures cleanly; hash tag conventions mean new code does not break cross-key ops by accident. After a year of disciplined operation, the cluster is boring, which is the highest praise a cache can earn.

• Performance. Right sharding supports throughput at scale; no shard becomes the bottleneck for the whole cluster.
• Operational fit. Hash tags match the actual workload; cross-key ops succeed without per-feature workarounds.
• Resilience. Even distribution survives node failures; failover does not concentrate load on neighbors.
• Institutional knowledge. Each shard teaches a Redis Cluster pattern; the team grows a vocabulary for sharded caching.

Redis Cluster operation is an operational discipline that pays off across years. Nova AI Ops integrates with Redis telemetry, surfaces shard patterns, and supports the team’s caching discipline.