How does Redis replication and high availability work?

Question

Accepted Answer

Redis provides **high availability** through **replication** (replica copies of the data), **Redis Sentinel** (automatic failover monitoring), and **Redis Cluster** (sharding + replication). Understanding these is important for running Redis reliably in production.

## Replication — primary and replicas

```text
PRIMARY (master) → handles writes; asynchronously replicates data to replicas
REPLICAS (slaves) → copies of the primary's data; can serve READS (read scaling)

Write → Primary → async replication → Replicas (eventually consistent)
  ✓ Redundancy (replicas have copies) + read scaling (reads offloaded to replicas)
  ✗ Replication is ASYNC → a small lag; a failover could lose very recent writes
```

Replicas asynchronously copy the primary's data — providing redundancy and read scaling (reads can go to replicas), though with slight replication lag.

## Redis Sentinel — automatic failover

```text
Replication alone doesn't auto-recover if the PRIMARY fails. REDIS SENTINEL adds:
  → MONITORING — Sentinels watch the primary and replicas
  → AUTOMATIC FAILOVER — if the primary fails, Sentinels elect a replica as the new primary
  → SERVICE DISCOVERY — clients ask Sentinel for the current primary address
→ Sentinel provides high availability (auto-failover) for a non-clustered setup.
  (Run multiple Sentinels — a majority must agree — to avoid false failovers.)
```

**Sentinel** monitors the setup and performs **automatic failover** (promoting a replica if the primary fails) — turning a primary failure into a brief interruption rather than an outage.

## Redis Cluster — sharding + HA

```text
REDIS CLUSTER → for scaling beyond one server's memory AND high availability:
  → SHARDS data across multiple primaries (each holds a subset via hash slots, 16384 total)
  → each primary has replicas (HA — a replica takes over if its primary fails)
  → scales horizontally (more memory/throughput) + built-in failover
→ Use Cluster when data exceeds one node's RAM or you need to scale writes.
```

## Why it matters

Understanding Redis replication and high availability is important for **running Redis reliably in production**, so it's valuable senior-level knowledge for production Redis deployments.

As Redis often holds important data (caches whose loss causes load spikes, sessions, queues), ensuring availability and redundancy matters. **Replication** (replicas asynchronously copying the primary) provides the foundation — redundancy (replicas hold copies) and read scaling (offloading reads to replicas) — though understanding its **asynchronous nature** (slight lag, potential loss of very recent writes on failover) is important for reasoning about consistency. **Redis Sentinel** is key for high availability in non-clustered setups: it adds **monitoring and automatic failover** (promoting a replica when the primary fails) plus service discovery, turning a primary failure into a brief interruption rather than an outage — essential for systems that must stay available (and running multiple Sentinels for majority agreement avoids false failovers). **Redis Cluster** addresses both scaling and HA: **sharding data across multiple primaries** (via hash slots, scaling beyond one server's memory and write throughput) with replicas for failover — necessary when data exceeds one node's RAM or writes must scale.

Understanding which to use (Sentinel for HA of a single dataset, Cluster for sharding + HA at scale) reflects sound operational judgment.

Since production Redis must be available and may need to scale, and since replication (redundancy/read scaling), Sentinel (automatic failover), and Cluster (sharding + HA) are Redis's mechanisms for reliability and scale, understanding Redis replication and high availability is important senior-level knowledge for deploying Redis reliably, a frequently-critical production concern and a topic demonstrating understanding of how to run Redis as a dependable part of the infrastructure rather than a single point of failure.