Redis Cluster Mode: Disabled vs. Enabled

Once you choose Redis, the next architectural decision is whether to enable Cluster Mode. This determines how your data is distributed and how you scale.

Cluster Mode Disabled: Single-Shard Architecture

In this mode, your entire dataset lives on one logical shard — one Primary node that handles all reads and writes.

• Topology: 1 Primary node + up to 5 Read Replica nodes.
• Read Scaling: Replicas can serve read traffic, distributing read load across up to 6 nodes total.
• Write Scaling: All writes go to the Primary. You cannot distribute write traffic.
• Data Distribution: 100% of your data lives on the Primary. Replicas hold full copies.
• Failover: If the Primary fails, ElastiCache automatically promotes one replica to Primary (typically within 60 seconds).
• Scaling Limit: You are bounded by the RAM of the largest available instance type. As of current AWS offerings, the largest Redis node (r6g.16xlarge) provides ~400GB of RAM. If your dataset exceeds this, Cluster Mode Disabled cannot help you.
• Use Case: Datasets under ~300GB, workloads where write throughput fits on a single node, simpler operational model.

Cluster Mode Enabled: Multi-Shard Architecture

In this mode, data is partitioned (sharded) across multiple independent shards. Each shard owns a subset of the keyspace.

• Topology: Up to 500 shards, each with 1 Primary + up to 5 Replicas.
• Sharding Mechanism: Redis uses hash slots. The keyspace is divided into 16,384 slots. Each shard owns a contiguous range of slots. When you write key user:1234, Redis computes CRC16("user:1234") % 16384 to determine which slot — and therefore which shard — owns that key.
• Write Scaling: Write traffic is distributed across all shard Primaries. 10 shards = 10x write capacity.
• Read Scaling: Each shard's replicas serve reads for that shard's keyspace.
• Data Distribution: Each key lives on exactly one shard. The total dataset is spread across all shards.
• Scaling Limit: Effectively unlimited for practical purposes. 500 shards × 400GB = ~200TB of addressable cache.
• Operational Complexity: Multi-key operations (MGET, MSET, transactions) only work if all keys hash to the same slot. Cross-slot operations require application-level coordination or the use of hash tags (e.g., {user}.profile and {user}.session both hash to the slot for user).
• Use Case: Datasets exceeding single-node capacity, write-heavy workloads requiring horizontal scale, applications that need to grow beyond a single node's throughput ceiling.