Redis High Availability

Redis HA modes

• ★ Redis Sentinel — master / replica + sentinel processes monitor and trigger failover. Default for HA single-key-space Redis.
• ★ Redis Cluster — sharded Redis across multiple nodes; resharding without downtime; required for huge data sets.
• Redis Replication only — primary + replicas, manual failover. Not really HA.

Operational managers

• Redis Operator (Spotahome) / Redis Operator (OT-Container-Kit) — k8s operators for HA Redis.
• Bitnami Redis Helm chart — common starting point.

Drop-in replacements (BSD-licensed; Redis went BSL/SSPL)

• ★ DragonflyDB — multi-threaded; much higher throughput per box; Redis-protocol-compatible. The default modern replacement.
• ★ KeyDB — multi-threaded fork of pre-license-change Redis; multi-master replication.
• Valkey (Linux Foundation) — fork of pre-license-change Redis, community-maintained.
• Garnet (Microsoft Research) — high-perf cache server; protocol-compatible-ish.

Specialized

• Upstash Redis — serverless Redis with HTTP API; works on Workers / Lambda / edge. Generous free tier.
• Memcached — older; simpler; no persistence; still used for pure caching.
• MemoryDB / ElastiCache (AWS) — managed.
• RedisLabs / Redis Cloud — paid hosted.

Connection pooling / proxies

• Twemproxy / nutcracker — older but still around.
• mcrouter — Memcached proxy from Meta.
• Envoy with Redis filter — modern.

Persistence / backups

• AOF — append-only-file; durability config matters (appendfsync everysec is the typical sweet spot).
• RDB snapshots — periodic; compact; great for backups.
• Both — AOF for durability, RDB for backups.
• SAVE / BGSAVE — manual.

Common patterns

Cache-only:

• Single Redis (or DragonflyDB) instance with no persistence.
• maxmemory-policy allkeys-lru.
• Recreate on failure; no HA needed.

Session store / queue / important data:

• Redis Sentinel: 1 primary + 2 replicas + 3 sentinels.
• AOF on; persistence disk-backed.
• PgBouncer-equivalent? Use HAProxy in TCP mode pointing at Sentinel-tracked master.

Big sharded data:

• Redis Cluster with 6+ nodes (3 shards × 2 replicas).
• Application-side cluster-aware client.

When to swap to DragonflyDB or KeyDB

• Single-Redis CPU is the bottleneck (multi-thread helps a ton).
• Memory efficiency matters (DragonflyDB uses far less RAM for same data).
• License concerns with current Redis BSL/SSPL terms.

When to skip Redis entirely

• Postgres can replace Redis for many use cases: LISTEN/NOTIFY, pg_kvstore patterns, pgmq for queues. One fewer service.
• Cloudflare Durable Objects for state at the edge.
• In-memory cache (lru-cache) in your app process for very hot reads.

Patterns to adopt

• ★ maxmemory-policy explicitly. Default is noeviction which can cause OOM-kills.
• Set TTLs aggressively to avoid stale data.
• Don't store huge objects — Redis chokes on multi-MB values.
• Pipeline / MGET for batches; don't issue 1000 single GETs.
• Watch slow log — slowlog get 10 regularly.
• Backup AOF / RDB to object storage; not just on the box.

Pick this if…

• Default cache, single-node: Redis (or DragonflyDB if you want speed).
• HA cache / queue: Sentinel or DragonflyDB cluster.
• Massive sharded: Redis Cluster.
• Edge / serverless: Upstash Redis.
• Tired of Redis license drama: DragonflyDB / Valkey / KeyDB.
• You're already on Postgres: consider pgmq / pg_kvstore and skip Redis.