Your Redis node is out of memory.
You add three more nodes. Still full, and nothing got faster.
You added copies of your data when what you actually needed was room for it.
Replication and sharding solve completely different problems. A replica is a full copy of the primary, which is great for reads and failover, but it buys you zero extra space. Sharding splits the key space so each primary owns a different slice. One cake cut across three plates, not the same cake run through a photocopier.
Cluster mode is how Redis does the slicing: 16,384 hash slots, CRC16 of the key picks the slot, and the slot owns the key, not the node.
What nobody warns you about is that flipping it on changes your application code:
→ MGET, MULTI, and Lua only run when every key hashes to the same slot. Otherwise you get CROSSSLOT.
→ Hash tags like {42} force keys together, and overusing them rebuilds the exact bottleneck you were escaping.
→ Only DB 0 exists. SELECT is gone.
→ Your one giant leaderboard still sits on a single node, because a key cannot be split. No amount of re-sharding fixes that. It's a data model change.
I broke the whole thing down visually: slots, MOVED vs ASK, gossip and failover, the async durability gap, and when ElastiCache's toggle actually earns its keep.
Top comments (0)