Designing a Highly Available Redis Service with Sentinel

Redis is the most commonly used in‑memory key‑value store for web applications, often employed for session storage, caching hot data, simple message queues, and Pub/Sub systems.

When providing Redis as a foundational service, callers inevitably ask whether the service is highly available, meaning it can continue operating or recover quickly after various failures.

The article defines three typical failure scenarios: (1) a Redis process on a node crashes, (2) an entire node goes down, and (3) network communication between two nodes is broken. High availability aims to tolerate any single‑point failure.

Four solution patterns are examined:

Single‑instance Redis (no Sentinel) : simple but suffers from a single point of failure.

Master‑slave with a single Sentinel : adds a backup slave and a Sentinel to monitor the master, but the Sentinel itself becomes a single point of failure.

Master‑slave with two Sentinels : adds redundancy for Sentinel monitoring, yet if one node and its Sentinel fail, the remaining Sentinel cannot achieve a quorum (50%+), so failover does not occur.

Master‑slave with three Sentinels (final solution) : introduces a third server running an additional Sentinel, allowing the system to survive any single‑process, single‑machine, or two‑machine network failure while still providing service.

The final architecture may also include a virtual IP (VIP) that always points to the current master; when a failover happens, a callback script moves the VIP to the new master, letting clients continue using a single IP address as if it were a standalone Redis instance.

Additional considerations such as configuring min‑slaves‑to‑write and min‑slaves‑max‑lag to prevent writes during network partitions, using Supervisor for process monitoring, and optionally adding a second slave for extra redundancy are discussed.

In summary, building a highly available Redis service requires multiple Redis instances, at least three Sentinel processes, and optional VIP handling to achieve seamless failover and maintain client usability.