From Single Node to Cluster: Mastering Redis Architecture Evolution

From the Simplest: Single‑Node Redis

First, we start with the simplest scenario: a single‑node Redis used as a cache in front of MySQL. When the business grows, a single node can become a bottleneck and a crash would force all traffic back to MySQL, causing overload.

To avoid data loss, we need persistence: writing memory data to disk. The naïve approach writes to disk synchronously, which hurts performance.

Persistence: Data Safety

Redis can off‑load disk writes to a background thread, which is the basis of the Append‑Only File (AOF) mechanism. AOF offers three fsync policies: always, no, and everysec.

AOF files grow over time; Redis provides AOF rewrite to shrink the file by keeping only the latest state.

Another persistence option is snapshotting (RDB), which writes a binary compressed snapshot at intervals, giving small file size and low write frequency.

Choosing between RDB and AOF depends on data‑loss tolerance: use RDB for cache‑only workloads, AOF for higher durability.

Hybrid Persistence

Redis 4.0+ supports hybrid persistence, which writes an RDB snapshot into the AOF during rewrite, reducing file size while keeping near‑real‑time durability.

Master‑Slave Replication: Multiple Copies

Deploying a master and one or more slaves provides redundancy and read‑scale. If the master fails, a slave can be promoted, but the promotion is manual and incurs downtime.

Sentinel: Automatic Failover

Sentinel processes monitor the master’s health. Multiple sentinels vote on master failure to avoid false positives, elect a leader, and the leader performs the failover automatically.

Sharding: Horizontal Scaling

When write traffic exceeds a single master’s capacity, a sharded cluster distributes keys across multiple nodes. Client‑side sharding or a proxy layer (e.g., Twemproxy, Codis) handles routing.

Official Redis Cluster uses the Gossip protocol for health checks and provides built‑in routing via client SDKs, eliminating the need for external sentinels.

Summary

Data loss protection – RDB/AOF persistence.

Long recovery time – master‑slave replicas.

Manual failover latency – Sentinel automatic failover.

Read pressure – replica scaling.

Write pressure/capacity – sharding clusters.

Community sharding solutions – Twemproxy, Codis.

Official sharding – Redis Cluster with Gossip.

Proxy + Redis Cluster – non‑intrusive client migration.

Following this progression from 0 to 1 and then to N, you can build a stable, high‑performance Redis deployment that scales with your business.