Understanding Redis: Architecture, Clustering, and Persistence Explained

1. What is Redis?

Redis (Remote DIctionary Service) is an open‑source key‑value database server.

More accurately, Redis is a data‑structure server, which makes it popular among developers.

Redis organizes data using data structures from the start, unlike iterative or sorting approaches. Early versions resembled Memcached, but Redis now supports many use cases such as publish‑subscribe, streaming, and queues.

In short, Redis is an in‑memory database often used as a cache in front of a “real” database (e.g., MySQL or PostgreSQL) to improve application performance by offloading frequent reads.

Data that is rarely changed but frequently requested

Low‑criticality data that changes often

Typical examples include session caches, leaderboard data, or aggregated analytics.

Redis can also serve as a primary database for many workloads, especially when combined with high‑availability plugins and configurations.

Because Redis stores data in memory, it offers much faster read/write speeds than SSD/HDD‑based databases.

Initially Redis was often compared to Memcached, which lacked persistent storage. Over time Redis added persistence, making it suitable for a broader set of scenarios.

Redis originally used snapshot‑based persistence (RDB) via asynchronous copying of memory, which could lose data between snapshots.

Redis has matured since its 2009 launch; the following sections cover its architecture and topology.

2. Redis Architecture

Before discussing Redis internals, we review common deployment options and their trade‑offs.

Single Redis instance

Redis high availability

Redis Sentinel

Redis Cluster

Choose the setup that matches your use case and scale.

Single Redis Instance

A single instance is the simplest deployment. It works well for small‑scale caching when sufficient memory and server resources are available. However, if the instance fails, all client requests to Redis fail.

When persistence is enabled, Redis forks a child process to create either an RDB snapshot or an AOF (Append‑Only File) log.

If persistence is disabled, data is lost on restart or failover.

Redis High Availability

High‑availability typically uses a master‑slave (primary‑replica) setup. Writes go to the master; replicas receive command streams to stay synchronized. Multiple replicas can improve read scalability and provide failover.

Redis Replication

Each master has a replication ID and offset. The offset increments with every operation. If a replica lags only a few offsets, it receives the missing commands (partial sync). If the offset gap is large or IDs differ, a full sync is triggered, sending a new RDB snapshot.

Replication IDs help determine the ancestry of replicas after failover or restart.

Redis Sentinel

Sentinel is a distributed system that provides high availability for Redis. A group of Sentinel processes monitors master and replica instances, detects failures, performs leader election, and updates clients with the current master address.

Monitoring – ensures masters and replicas work as expected.

Notification – alerts administrators of events.

Failover management – promotes a replica to master when needed.

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

Sentinel uses a quorum of nodes to decide on failover, preventing split‑brain scenarios.

Redis Cluster

Cluster enables horizontal scaling by sharding data across multiple nodes. Each node holds a subset of hash slots (16,384 total). Keys are hashed and mapped to a slot, which determines the owning node.

When adding a new node, hash slots are re‑assigned without moving individual keys, minimizing downtime.

Cluster uses a gossip protocol for health monitoring. If a majority of nodes agree that a master is unreachable, a replica is promoted.

3. Redis Persistence Model

Understanding persistence is essential when data durability matters.

No Persistence

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

RDB (Redis Database)

RDB creates point‑in‑time snapshots at configured intervals. Snapshots can cause data loss between intervals and rely on fork, which may introduce latency for large datasets.

AOF (Append‑Only File)

AOF logs every write operation. On restart, the log is replayed to rebuild the dataset. AOF offers better durability than RDB but consumes more disk space.

Hybrid (RDB + AOF)

Both can be enabled: RDB for fast restarts, AOF for full durability. On restart, Redis prefers AOF to reconstruct data.

Forking and Copy‑On‑Write

Redis uses fork and copy‑on‑write to create snapshots efficiently. The child process writes the snapshot while the parent continues serving requests; only modified memory pages are duplicated.

Through this mechanism, Redis can capture a consistent in‑memory snapshot without pausing the service.