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. It is more accurately described as a data‑structure server, which makes it popular among developers.

Redis organizes data by data structures from the start, rather than using iteration or sorting. Early uses resembled Memcached, but Redis now supports many use cases such as publish‑subscribe, streaming, and queues.

Primarily, 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 frequently requested or less‑critical data.

Data that is infrequently changed but frequently requested.

Low‑criticality data that changes often.

These examples include session caches, leaderboard rankings, or aggregated analytics.

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

Redis blurs the line between cache and data store; accessing data in memory is much faster than using SSD/HDD storage.

Feature

Memcached

Redis

Sub‑millisecond latency

Yes

Yes

Developer friendliness

Yes

Yes

Data partitioning

Yes

Yes

Broad 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

Initially compared to Memcached, Redis added persistence via snapshots, though early snapshots could lose data between saves.

Redis Architecture

Before discussing internal structures, consider the various Redis deployment options and their trade‑offs.

Single Redis instance

Redis high availability (master‑slave)

Redis Sentinel

Redis Cluster

Single Redis instance is the simplest deployment. It runs a small instance that can provide significant performance gains for caching scenarios, but if the instance fails, all clients lose access.

When persistence is enabled, Redis forks a child process to generate RDB snapshots or AOF logs at intervals.

Redis high availability uses a master‑slave setup where writes go to the master and are replicated to one or more slaves, enabling read scaling and failover.

Redis replication assigns each master a replication ID and offset. Slaves that fall only a few offsets behind can catch up incrementally; otherwise a full sync is performed by sending a new RDB snapshot.

Redis Sentinel is a distributed system of sentinel processes that monitor master and slave health, provide automatic failover, and act as a service discovery mechanism for clients.

Monitoring – ensure masters and slaves operate as expected.

Notification – alert administrators of events.

Failover management – promote a slave to master when needed.

Configuration management – expose the current master to clients.

Redis Cluster enables horizontal scaling by sharding data across multiple nodes. Keys are hashed to determine the slot (0‑16383) and thus the shard that stores them. Re‑sharding moves hash slots between nodes without moving individual keys.

Cluster health is maintained via a gossip protocol; a quorum of nodes must agree before promoting a new master to avoid split‑brain scenarios.

Redis Persistence Model

Redis offers several persistence options:

No persistence – fastest operation, no durability.

RDB (snapshot) – periodic point‑in‑time snapshots; may lose data between snapshots and incurs fork overhead.

AOF (append‑only file) – logs every write operation; more durable but larger and slower to load.

RDB + AOF – combines both for speed and durability; on restart, AOF is used to rebuild data.

Redis uses fork and copy‑on‑write to create snapshots efficiently without exhausting memory.