Unlocking Redis: Architecture, High Availability, and Persistence Explained

1. What is Redis?

Redis (Remote DIctionary Service) is an open‑source in‑memory key‑value database server that functions as a data‑structure server, which makes it popular among developers.

Redis does not process data by iteration or sorting; instead, it organizes data from the start using rich data structures. Early versions resembled Memcached, but Redis has evolved to support publish‑subscribe, streaming, and queue use cases.

Typically, Redis is used as an in‑memory cache in front of a "real" database such as MySQL or PostgreSQL to improve application performance by leveraging fast memory access.

Data that is rarely changed but frequently requested.

Data that is not mission‑critical yet changes often.

Examples include session storage, data caches, leaderboards, and aggregated analytics.

2. Redis Architecture

Before diving into Redis internals, we review common deployment patterns and their trade‑offs.

Single Redis instance

Redis high availability

Redis Sentinel

Redis Cluster

2.1 Single Redis Instance

A single instance is the simplest deployment, suitable for small‑scale services or when sufficient memory and server resources are available. If the instance fails, all client requests to Redis fail, affecting overall system performance.

When persistence is enabled, Redis forks a child process to generate either an RDB snapshot or an AOF file at configured intervals.

2.2 Redis High Availability (Master‑Slave)

In a master‑slave setup, write operations go to the master, which asynchronously replicates commands to one or more slave instances. This improves read scalability and provides fail‑over capability.

2.3 Redis Replication Details

Each master has a replication ID and an offset. The offset increments with every operation. When a replica lags only a few offsets behind, it receives the missing commands and replays them. If the IDs differ, a full sync is triggered, creating a new RDB snapshot for the replica.

2.4 Redis Sentinel

Sentinel is a distributed system that monitors master and slave instances, notifies administrators of events, manages fail‑over, and provides service discovery for clients.

Monitoring – ensures masters and slaves are responsive.

Notification – alerts administrators of instance events.

Fail‑over management – promotes a replica to master when a quorum of Sentinels agrees the master is unavailable.

Configuration management – acts as a discovery service for the current master.

2.5 Redis Cluster

Redis Cluster enables horizontal scaling by sharding data across multiple nodes. Keys are hashed and the hash slot (0‑16383) determines the owning node.

When adding a new node, hash slots are moved between existing nodes without moving individual keys, minimizing downtime.

2.6 Gossip Protocol

Cluster nodes continuously gossip to share health information. If a majority of nodes agree that a master is unreachable, they promote a replica to maintain cluster health. Proper quorum configuration prevents split‑brain scenarios.

3. Redis Persistence Model

Redis offers several persistence options, each with trade‑offs between speed and durability.

3.1 No Persistence

Disabling persistence yields the fastest performance but provides no durability guarantees.

3.2 RDB Snapshots

RDB creates point‑in‑time snapshots at configured intervals. While fast to load, snapshots can lose data between intervals and rely on fork, which may cause latency spikes for large datasets.

3.3 AOF (Append‑Only File)

AOF logs every write operation. On restart, the log is replayed to rebuild the dataset. It offers stronger durability than RDB but consumes more disk space and can be slower.

3.4 Combining RDB and AOF

Both can be enabled; on restart, Redis prefers AOF for reconstruction because it is more complete.

3.5 Forking for Persistence

Redis uses the operating system's fork and copy‑on‑write mechanism to create a child process that writes snapshots or AOF files without blocking the parent process. Only pages that change after the fork are copied, allowing efficient snapshot creation even for large memory footprints.