In ElastiCache for Valkey or Redis OSS, what is the difference between a replication group with cluster mode disabled and one with cluster mode enabled, and what does that choice force on the application's client library?

## Two shapes of the same replication group ElastiCache calls both of these a *replication group*, which hides how differently they behave. The switch is `cluster mode`, and it decides whether the cache is one shard or many. ## Cluster mode disabled A cluster-mode-disabled replication group has exactly **one shard**: - one primary node holds the **entire** keyspace; - up to five read replicas hold copies; - the group exposes a **primary endpoint** (always the current primary) and a **reader endpoint** (spread across the replicas). What this means for capacity is the part candidates get wrong. Replicas do not add write throughput and do not add memory — every replica holds the same full dataset. The only way to hold more data or absorb more writes is a **larger node type**, which ElastiCache performs online but with a failover along the way. The whole working set must fit in one node's memory, minus the headroom the engine needs. What you get in exchange is simplicity: any ordinary client works, multi-key commands and scripts have no placement restriction, and there is exactly one topology to reason about. ## Cluster mode enabled A cluster-mode-enabled replication group has **many shards** (AWS calls them node groups). The keyspace is partitioned across 16,384 hash slots, and each shard owns a contiguous range of them. Every shard has its own primary and its own replicas, and every shard fails over independently. Capacity now scales in two dimensions: memory and write throughput both grow as you add shards, because each primary owns only its slice. ElastiCache supports **online resharding** — adding or removing shards and rebalancing slot ownership while the cluster keeps serving — and you can drive shard or replica counts with ElastiCache Auto Scaling target-tracking policies. ## What it forces on the client This is the operational heart of the question: 1. **The library must support cluster mode.** It connects to the configuration endpoint, retrieves the slot-to-node map, and opens connections to every shard. When a slot moves — a resharding, a failover — the server answers with a redirection and the client must follow it and refresh its cached map. A plain non-cluster client pointed at the configuration endpoint will work by accident for keys that happen to land on the node it reached, and fail for everything else. 2. **Multi-key work is constrained.** A command touching several keys, a transaction, or a script must operate on keys that hash to the same slot; otherwise the server rejects it. Applications that batch reads across unrelated keys need reworking before the move. 3. **Connection count grows.** Instead of one pool to a primary, the client maintains connections per shard, which matters for connection-heavy runtimes. ```bash # Three shards, one replica each — cluster mode enabled aws elasticache create-replication-group \ --replication-group-id app-cache \ --replication-group-description "sharded app cache" \ --engine valkey \ --cache-node-type cache.m7g.large \ --num-node-groups 3 \ --replicas-per-node-group 1 \ --automatic-failover-enabled \ --multi-az-enabled ``` `--num-node-groups` greater than one is what makes it a sharded cluster; the same call with `--num-node-groups 1` and no sharding intent is the cluster-mode-disabled shape. ## How to choose Start from the dataset and the write rate: - **Cluster mode disabled** when the working set fits comfortably in one node type you are willing to pay for, writes fit within one primary, and the application uses multi-key operations freely. It is less to operate and less to get wrong. - **Cluster mode enabled** when the dataset is larger than a single node, is growing unpredictably, or the write rate exceeds one primary. Also when you want failure to be partial rather than total: one shard's failover disturbs a fraction of the keyspace instead of all of it. ## The migration path You are not locked in. ElastiCache supports migrating a cluster-mode-disabled replication group to cluster mode enabled online. The ordering that matters is the client: deploy a cluster-capable client and fix multi-key access paths **before** the migration, because the day the topology changes is the wrong day to discover a library that cannot follow a redirection. ## What candidates get wrong The two classic errors are believing that adding replicas increases write capacity, and assuming any client works against a sharded cluster. A third, subtler one is treating cluster mode enabled as the safe default: for a modest cache it adds client requirements and access-pattern restrictions in exchange for scale you do not need yet.