Replication & High Availability

Persistence (Lesson 7) lets Redis survive a restart, but not a server failure — if the machine dies, a single Redis instance is down until someone rebuilds it, and that’s an outage. Replication and Sentinel make Redis highly available: copies on other machines, and automatic promotion when the primary fails. This lesson is how Redis stays up when a server doesn’t.

Replicas: copies that scale reads and stand ready

Replication means running replicas (read-only copies) that stay in sync with a primary. A replica continuously receives the primary’s write stream and applies it, so it holds the same data. Replication does two jobs:

• Scale reads. Replicas are read-only but fully queryable, so you can point read traffic at replicas and keep writes on the primary. For a read-heavy workload (most caches), this multiplies read capacity — add replicas, spread the reads. (Writes don’t scale this way; they all go to the one primary. For write scaling you need sharding — Lesson 9.)
• Stand ready for failover. A replica holds a current copy, so if the primary dies, a replica can be promoted to become the new primary with minimal data loss. This is the foundation of high availability.

Replication is asynchronous: the primary doesn’t wait for replicas to confirm before acknowledging a write (that would add latency). This keeps writes fast, but has a consequence we’ll return to.

Sentinel: automatic failover

Replicas enable failover, but someone or something has to notice the primary died, pick a replica, promote it, and tell clients the new address. Doing that by hand at 2 a.m. is an outage you don’t want. Redis Sentinel automates it.

Sentinel is a set of lightweight processes (run an odd number, usually 3, so they can reach a majority) that monitor the primary and replicas. When the primary stops responding:

1. The Sentinels agree (a quorum) that the primary is genuinely down — not just a network blip from one Sentinel’s view. This agreement avoids a single confused Sentinel triggering an unnecessary failover.
2. They elect and promote one of the replicas to be the new primary.
3. They reconfigure the other replicas to follow the new primary, and notify clients (which ask Sentinel for the current primary’s address) to reconnect to it.

The result is automatic failover: the primary dies, and within seconds the system has promoted a replica and redirected clients, with no human involved. Clients connect through Sentinel (asking “who’s the primary?”) so they always find the current one. This is the standard high-availability setup for a Redis dataset that fits on one machine.

The async-replication trade-off

There’s an honest caveat, and it’s the same durability-vs-availability trade that runs through all distributed systems (and the Kafka and distributed systems courses). Because replication is asynchronous, when the primary fails, the most recent writes may not have reached the replica yet — and those writes are lost when a replica is promoted. The window is usually small (milliseconds of writes), but it’s non-zero.

So Redis failover prioritises availability (stay up, fast writes) over perfect durability (never lose a single write). For most uses that’s the right call. If you genuinely cannot lose any write, you combine this with AOF persistence (Lesson 7) and accept that the absolute-strongest guarantees (synchronous replication) cost latency Redis usually chooses not to pay. The WAIT command exists to block until a write reaches N replicas, giving stronger durability on demand at a latency cost — use it for the rare writes that need it.

HA vs scaling: a preview

Replicas + Sentinel give you high availability for a dataset that fits on one machine — one primary (plus read replicas), automatically failed over. What they don’t give you is horizontal scale beyond one machine’s RAM or write throughput: all writes still go to a single primary, and the whole dataset must fit in one box’s memory.

When you outgrow that — the dataset is too big for one machine, or write throughput exceeds one primary — you need sharding, which is Redis Cluster (the next lesson). Cluster shards the data across multiple primaries and provides HA (each shard has replicas and automatic failover), so it gives you sharding and high availability together. The rule of thumb: single primary + replicas + Sentinel while one machine suffices (which is a long way — Redis is fast and RAM is large); Cluster when you must shard across machines. Start simple; scale out only when you genuinely need to.

Pitfalls to Avoid

1. A single instance with no replica. One machine failure = outage (and, without persistence, data loss). For anything production, run at least one replica and Sentinel for automatic failover.
2. An even number of Sentinels. Sentinel needs a majority to agree on a failover; 2 can’t form a reliable quorum. Run an odd number (3 is standard), ideally across failure domains.
3. Writing to replicas. Replicas are read-only; writes must go to the primary. Sending writes to a replica fails (or is lost). Route reads to replicas, writes to the primary — and after a failover, to the new primary (via Sentinel).
4. Assuming failover loses nothing. Async replication means a failover can drop the last few un-replicated writes. For writes you can’t lose, add AOF and consider WAIT; accept the availability/durability trade.
5. Clients hardcoding the primary’s address. After a failover the primary is a different node. Clients must discover the current primary via Sentinel (or a cluster-aware client), not a fixed IP.
6. Using replication to scale writes. All writes go to one primary — replicas only scale reads. For write scaling or a dataset bigger than one machine, you need Cluster (Lesson 9), not more replicas.

Quick Recap

• A single instance is a single point of failure. Replicas are read-only copies kept in sync (async) that scale reads and stand ready to take over. Writes go only to the primary.
• Sentinel (an odd number, usually 3) monitors the primary and, on failure, agrees it’s down, promotes a replica, and redirects clients — automatic failover. Clients find the current primary via Sentinel.
• Replication is async, so a failover can lose the last few un-replicated writes — the durability-vs-availability trade. Pair with AOF (and WAIT for critical writes) if needed.
• Replicas + Sentinel = HA for a dataset that fits one machine. To shard across machines (more RAM/write throughput), use Redis Cluster (next), which gives sharding and HA.

Next lesson: scaling beyond one machine — Redis Cluster and sharding (hash slots).