Understanding Redis: Architecture, Deployment Options, Persistence Models, and High Availability

Redis (Remote Dictionary Service) is an open‑source, in‑memory key‑value store that functions as a data‑structure server, making it popular among developers for use cases beyond simple caching, including publish/subscribe, streams, and queues.

Redis is typically deployed as a cache in front of a persistent database (e.g., MySQL or PostgreSQL) to accelerate read‑heavy workloads, storing infrequently changed data, session information, leaderboards, and aggregated analytics.

Deployment Options

Single Redis instance – the simplest setup, suitable for small‑scale caching when sufficient memory and resources are available.

Redis high availability – master‑slave replication with automatic failover.

Redis Sentinel – a distributed system that monitors masters and slaves, provides alerts, performs leader election, and manages configuration discovery.

Redis Cluster – horizontal scaling using sharding, hash slots, and gossip protocol for health monitoring.

Replication

Each master has a replication ID and offset; replicas synchronize by receiving command streams or full snapshots when offsets diverge. Replication IDs help determine data ancestry during failover and partial sync.

Sentinel

Sentinel processes collaborate to monitor master/slave health, notify administrators, and trigger failover when a quorum of nodes agrees the master is unavailable.

Feature

Memcached

Redis

Sub‑millisecond latency

Yes

Yes

Developer friendliness

Yes

Yes

Data partitioning

Yes

Yes

Wide language support

Yes

Yes

Advanced data structures

-

Yes

Multithreaded architecture

Yes

-

Snapshots

-

Yes

Replication

-

Yes

Transactions

-

Yes

Publish/Subscribe

-

Yes

Lua scripting

-

Yes

Geospatial support

-

Yes

Persistence Models

No persistence – fastest but no durability.

RDB – point‑in‑time snapshots taken at configured intervals; fast loading but may lose data between snapshots.

AOF – logs every write operation; more durable but larger files and slower writes.

RDB + AOF – combines both for a balance of speed and durability; on restart Redis prefers AOF for reconstruction.

Redis uses a fork‑and‑copy‑on‑write mechanism to create snapshots without blocking the main process, allowing efficient persistence even for large datasets.

Cluster Sharding and Re‑sharding

Redis Cluster distributes data across multiple nodes using 16,384 hash slots. Keys are hashed and mapped to a slot; each node owns a range of slots. Adding a new node involves moving hash slots, not individual keys, enabling seamless scaling with minimal downtime.

Gossip Protocol

Cluster nodes continuously exchange health information via a gossip protocol. If a majority of nodes detect a master failure, they promote a replica to master, ensuring high availability. Proper quorum configuration (odd number of masters, at least two replicas) prevents split‑brain scenarios.

Overall, Redis has evolved from a simple cache to a versatile, highly available data store with rich data structures, robust replication, and scalable clustering capabilities.