Redis Cluster Explainer

Redis stores data in RAM, so reads and writes are extremely fast (microseconds). Each Redis instance executes commands on a single thread, which means commands are atomic by default — no locks needed. Newer versions (6+) have I/O threads for network handling, but command logic is still serialized.

Each key is mapped to one of 16384 slots using CRC16(key) mod 16384. Slots are divided across master shards. To force two keys onto the same shard, wrap the common part in {} — Redis will only hash the part inside the braces.

Example: {user:42}:profile and {user:42}:cart hash user:42 only, so both land on the same slot/shard. This lets you use multi-key commands (MGET, transactions, Lua) across them.

Each master can have N replicas. Writes go to the master, then are streamed asynchronously to replicas. This means replicas may lag — on master failure, the promoted replica might miss the most recent writes (data loss window).

Redis supports WAIT numreplicas timeout for stronger guarantees, but it's not synchronous by default for performance reasons.

Cluster nodes constantly gossip with each other via PING/PONG. If a node misses replies for cluster-node-timeout, others mark it as PFAIL (possibly failed). Once a majority of masters agree, it becomes FAIL.

The dead master's replicas request votes from surviving masters. The replica with the most up-to-date replication offset wins, runs REPLICAOF NO ONE, claims the slots, and gossips its new role.

You need a majority of masters alive — that's why production clusters use 3+ masters across failure domains.

• MOVED <slot> <node>: client hit a node that doesn't own this slot anymore. The slot has permanently moved. Client should update its slot map and retry on the new node.
• ASK <slot> <node>: slot is currently migrating. The key may already be on the destination. Client retries on the destination with an ASKING prefix, but does NOT update its permanent slot map.

• true (default): refresh topology from all known nodes — masters and replicas. Resilient if the original seeds die.
• false: refresh topology only from the seed nodes originally configured. Lighter network traffic, but if all seeds are dead the client can't discover new topology.

Pair this with enablePeriodicRefresh and enableAllAdaptiveRefreshTriggers for production-grade resilience.

• RDB: point-in-time binary snapshot, dumped every N seconds / M changes. Fast restart, smaller files, but you lose the last few seconds on crash.
• AOF: append-only log of every write command. Replayed on startup. Slower to load, larger files, but durability up to fsync policy (always / everysec / no).
• Most production setups run both.

• noeviction — reject writes (default)
• allkeys-lru / allkeys-lfu — evict any key by recency / frequency
• volatile-lru / volatile-ttl — only evict keys with TTL set
• allkeys-random, volatile-random — random eviction

Redis supports strings, lists, sets, hashes, sorted sets, streams, bitmaps, hyperloglogs, and geospatial indexes. Atomic ops via MULTI/EXEC, Lua scripts, and FUNCTION.

On the CAP triangle, Redis Cluster favors AP — it stays available during partitions but async replication means writes can be lost on failover. For stronger consistency, consider WAIT or external coordination (e.g., RedLock).