Designing a High‑Availability Redis Service with Sentinel

Redis is widely used as an in‑memory key‑value store for session storage, hot‑data caching, simple message queues, and pub/sub, but a single Redis instance suffers from single‑point‑of‑failure risks.

High availability is defined as the ability to continue serving requests despite various failures, such as a process crash, an entire server outage, or network partition between nodes.

Solution 1 – a standalone Redis server – is simple but cannot survive any of the above failures; data loss and service interruption occur if the process or host stops.

Solution 2 – master‑slave replication with a single Sentinel – adds a backup slave and a Sentinel that promotes the slave when the master fails, yet the Sentinel itself becomes a single point of failure.

Solution 3 – master‑slave with two Sentinels – tries to eliminate the Sentinel bottleneck, but Redis requires a majority (more than 50 %) of Sentinels to agree on a failover; with only two Sentinels, a network split can leave the quorum unmet, preventing automatic master promotion.

Solution 4 – master‑slave with three Sentinels (and optionally a third Redis node) – provides true high availability: any single process, host, or network partition can be tolerated, and the remaining Sentinels can achieve quorum to promote a new master. Additional slaves can be added for extra redundancy, though too many increase replication lag.

To keep client usage simple, 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 connecting to a single address just like a standalone Redis.

In conclusion, building a highly available Redis service is straightforward at a basic level but becomes complex when ensuring failover, data consistency, and seamless client experience; the three‑Sentinel architecture with VIP and process supervision (e.g., Supervisor) offers a practical balance.