The Redis Reliability Guide

Sentinel gives one dataset, replicated, with monitored automatic failover; it fits estates that need availability rather than capacity. Cluster shards the keyspace across nodes with a replica per shard; it fits datasets that do not fit one node or throughput that does not fit one core, and it changes how clients and multi-key commands behave. Both fail over; they fail over differently, and clients must be configured for whichever one you run.

The dataset is not the memory requirement. Add replication buffers, client output buffers, and the copy-on-write overhead of a fork during a snapshot or a full sync, and size to the peak of all of that. Then set maxmemory and an eviction policy that matches the workload: an LRU or LFU policy for a cache, noeviction only where a write error is genuinely preferable to losing a key. The default is noeviction, and most first outages are that default meeting a full instance.

Not a leak. Fragmentation after churn on values of varying size, a small number of very large values, streams or lists that grow without trimming, and client output buffers for slow consumers all grow memory without adding keys. INFO memory and the memory-usage commands per key find it; active defragmentation and value trimming fix most of it.

Redis is single-threaded for commands, so one slow command, a KEYS in production, a large SMEMBERS, a Lua script, delays everything behind it. A fork for RDB or AOF rewrite can stall the process on a busy instance. A connection pool that is too small queues on the client side and looks like a server timeout. The slow log and latency monitoring separate the three; the fix is different for each.

A documented failover is a hypothesis. Kill the primary with clients connected and watch what happens: how long Sentinel takes to promote, whether clients reconnect to the new primary or keep writing to a stale one, whether a Cluster slot migration completes, and what the application does with the writes that were in flight. Time it; that is your real recovery time.

Most Redis incidents are found in four places: the slow log, INFO memory and persistence sections, the client list, and the replication state. The troubleshooting post gives the sequence; the escalation question is whether the fix is in your runbook or whether it is a replication, persistence or cluster-topology problem where a wrong step loses data.

Valkey forked from Redis 7.2 under the Linux Foundation, and everything above applies to it: the same HA modes, memory model, eviction policies and single-threaded command path. The divergences are specific and knowable, and they mostly concern newer features and tooling. Whether to migrate is a licensing and governance decision more than a technical one.