Understanding Redis: Overview, Architecture, and Persistence Model

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

Redis organizes data by data structures rather than by iteration or sorting, and its use cases have expanded beyond simple caching to include publish‑subscribe, streaming, and queuing.

Primarily, Redis acts as an in‑memory cache in front of a persistent database (e.g., MySQL or PostgreSQL) to improve application performance by serving frequently requested or rarely changed data such as sessions, leaderboards, or aggregated analytics.

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

Compared with traditional disk‑based databases, Redis offers much faster read/write speeds because data resides in memory.

Key feature comparison between Memcached and Redis:

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

Pub/Sub

-

Yes

Lua scripting

-

Yes

Geospatial support

-

Yes

Redis deployment models covered include:

Single Redis instance

Redis high availability (master‑slave replication)

Redis Sentinel

Redis Cluster

Single Redis instance is the simplest deployment, suitable for small‑scale caching when sufficient memory and server resources are available. Persistence can be enabled via RDB snapshots or AOF logs, which are generated by a forked child process.

Redis high availability uses master‑slave replication; writes go to the master and are asynchronously replicated to one or more slaves, providing read scaling and failover capability.

Redis replication relies on a replication ID and offset to track synchronization state. Partial sync occurs when a replica is only slightly behind; full sync (snapshot transfer) happens when IDs diverge.

Redis Sentinel is a distributed system of sentinel processes that monitor master and slave instances, provide automatic failover, and act as a service discovery mechanism. Sentinel ensures high availability by requiring a quorum of nodes before promoting a slave to master.

Sentinel responsibilities include monitoring, notifying administrators, managing failover, and maintaining configuration.

Sentinel quorum examples (number of servers vs. quorum vs. tolerated failures):

Number of Servers

Quorum

Number Of Tolerated Failures

1

1

0

2

2

0

3

2

1

4

3

1

5

3

2

6

4

2

7

4

3

Redis Cluster enables horizontal scaling by sharding data across multiple nodes. Keys are hashed and mapped to one of 16,384 hash slots; each node owns a subset of slots. Re‑sharding involves moving hash slots rather than individual keys.

Example hash‑slot distribution:

M1 owns slots 0‑8191

M2 owns slots 8192‑16383

When a new node M3 is added, slots are redistributed (e.g., M1: 0‑5460, M2: 5461‑10922, M3: 10923‑16383), and only the affected slots need to be moved.

Cluster health is maintained via a gossip protocol where nodes exchange status information. If a majority agrees a master is down, a slave is promoted, provided the quorum configuration prevents split‑brain scenarios.

Redis persistence models :

No persistence : fastest operation, no durability.

RDB (Redis Database) snapshots : periodic point‑in‑time snapshots; may lose data between snapshots; uses forked process.

AOF (Append‑Only File) : logs every write command; can be fsynced to disk; more durable but larger and slower than RDB.

Hybrid (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: the child process gets a shared memory view of the parent; only modified pages are copied, allowing fast, low‑overhead persistence even for large datasets.

Overall, Redis provides a versatile in‑memory data store with rich data structures, multiple deployment topologies, and configurable persistence options suitable for caching, real‑time analytics, and even primary data storage.