Designing a High‑Availability Redis Service with Sentinel

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

When providing Redis as a foundational service, callers inevitably ask about its high‑availability (HA) guarantees, prompting the need for a design that can survive various failure scenarios.

HA is defined as the ability to continue serving requests despite anomalies such as a single Redis process crash, an entire server outage, or a network partition between nodes.

The guiding principle is that the system should tolerate any single‑point failure, assuming multiple independent failures are extremely unlikely.

Among many existing HA solutions (Keepalived, Codis, Twemproxy, Redis Sentinel), the author chose the official Redis Sentinel because the workload does not require a large cluster.

Redis Sentinel monitors Redis instances and automatically promotes a replica (slave) to master when the current master becomes unavailable, providing transparent failover to clients.

Scheme 1: Single Redis instance without Sentinel – simple but suffers from a single point of failure; if the process or server stops, the service is lost and data may be lost without persistence.

Scheme 2: Master‑slave with a single Sentinel – adds a replica and a Sentinel for monitoring, but the Sentinel itself is a single point of failure, so true HA is not achieved.

Scheme 3: Master‑slave with two Sentinels – adds redundancy for Sentinel, but Redis requires a majority (over 50%) of Sentinels to be reachable to perform a failover; with only two Sentinels, a single network partition prevents promotion, leaving the service unavailable.

The 50% quorum rule prevents split‑brain scenarios where two masters could accept writes, leading to data inconsistency.

Scheme 4: Master‑slave with three Sentinels – the final architecture uses three Sentinel processes across three servers to manage two Redis instances, ensuring that any single server or process failure still leaves a majority of Sentinels to elect a new master.

Optionally, a third Redis instance can be added to form a 1‑master + 2‑slave topology, further improving redundancy at the cost of replication overhead.

To simplify client configuration, a virtual IP (VIP) can be assigned to the current master; when a failover occurs, a script moves the VIP to the new master, allowing clients to continue using a single IP and port.

In conclusion, building a highly available Redis service involves adding replicas, multiple Sentinel processes, and optional VIP handling; the three‑Sentinel design provides resilience against process crashes, server outages, and network partitions while keeping client usage straightforward.