What Is Redis? A Deep Dive into Its Architecture and Persistence

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, rather than iterating or sorting. Early versions resembled Memcached, but Redis has evolved to support use cases such as publish‑subscribe, streaming, and queues.

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

Data that is infrequently changed but frequently requested

Low‑criticality data that changes often

Examples include session caches, leaderboard rankings, or aggregated analytics.

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

Redis blurs the line between cache and storage; accessing data in memory is far faster than using SSD/HDD‑based databases.

Sub‑millisecond latency: both Memcached and Redis support.

Developer friendliness: both support.

Data partitioning: both support.

Broad language support: both support.

Advanced data structures: Redis only.

Multithreaded architecture: Memcached only.

Snapshot capability: Redis only.

Replication: Redis only.

Transactions: Redis only.

Pub/Sub: Redis only.

Lua scripting: Redis only.

Geospatial support: Redis only.

Initially, Redis used snapshot persistence, which could lose data between snapshots. Since 2009 Redis has matured, and its architecture and topology can be added to your data‑storage system.

Redis Architecture

Before discussing Redis internals, consider deployment options and trade‑offs.

Single Redis instance

Redis high availability

Redis Sentinel

Redis Cluster

Single Redis instance is the simplest deployment, suitable for small setups or caching scenarios. It runs on a single machine; if it fails, all clients lose access.

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

Redis high availability uses a master‑slave replication model. Writes go to the master and are replicated to one or more slaves, providing read scaling and failover.

Redis replication assigns each master a replication ID and offset. Slaves that fall slightly behind receive incremental updates; larger gaps trigger a full sync via a new RDB snapshot.

Redis Sentinel is a distributed system of sentinel processes that monitor master and slave health, perform automatic failover, and provide service discovery.

Monitoring – ensure master/slave instances work as expected.

Notification – alert administrators of events.

Failover management – promote a slave when the master is unavailable.

Configuration management – act as discovery service for the current master.

Sentinel uses a quorum of nodes to decide on failover, avoiding single points of failure.

Redis Cluster enables horizontal scaling by sharding data across multiple nodes. Each key is hashed to a slot (0‑16383); slots are assigned to nodes (shards).

When adding a new node, hash slots are moved between existing nodes without full data migration, minimizing downtime.

Cluster health is maintained via a gossip protocol; nodes exchange status to detect failures and promote replicas.

Redis Persistence Model

Redis offers several persistence options:

No persistence – fastest, no durability guarantees.

RDB (Redis Database) – point‑in‑time snapshots at configured intervals; may lose data between snapshots.

AOF (Append‑Only File) – logs every write operation; can be fsynced to disk for durability, but uses more space.

RDB + AOF – combines both; on restart, AOF is used to rebuild the dataset.

Redis uses fork and copy‑on‑write to create snapshots efficiently without blocking the main process, allowing large datasets to be persisted with minimal performance impact.