Redis Architecture

Mental Model

Redis (Remote Dictionary Server) is a high-performance, in-memory, key-value database designed to serve millions of reads and writes per second with sub-millisecond latency.

Unlike standard disk-backed databases, Redis keeps all keys and data structures in RAM. To achieve high throughput without locks or race conditions, it processes commands sequentially in a single-threaded event loop. For reliability and scalability, Redis supports replication, failover via Sentinel, write partitioning via Cluster Sharding, and persistence configurations (RDB and AOF) to reload memory from disk after crashes.

graph TD
    App[Client Pool / Application Servers] -->|1. Read/Write| Redis[Redis Primary Node]
    Redis -->|2. Async Replication| Replica[Redis Replica Nodes]
    Redis -.->|3. Write-Behind| Disk[Disk Storage RDB/AOF]
    App -->|4. Cache Miss Fallback| DB[(Main Database)]

---

Components and Why They Exist

Client Pool (Application Servers)

The client pool of application servers (App Server 1, App Server 2, and App Server 3) runs the client-facing logic that queries and updates data. Each server dispatches GET and SET commands to the Redis Primary first, falling back to the Main Database on a cache miss before populating the resulting value back into the in-memory store.

Redis Primary (Primary Instance)

The primary instance serves as the single-threaded write coordinator and authoritative in-memory store. Its single-threaded event loop processes client write commands sequentially without locking overhead, updates key structures in RAM, enforces TTL expirations, and streams replication state updates to replicas.

Redis Replicas / Shards

Replica and shard nodes scale read throughput or partition memory across a cluster:

• Replicas: Maintain read-only copies of the primary instance to absorb heavy read query traffic and stand ready for Sentinel promotion.
• Shards: Divide the keyspace into 16,384 logical hash slots so keys distribute across separate cluster nodes during sharded phases.

Main Database

The main database provides transactional, durable disk storage of record (such as PostgreSQL). It handles authoritative writes and slower SELECT fallback queries whenever a requested key misses the Redis cache or has expired.

Disk Storage (AOF & RDB)

Disk storage persistence prevents complete data loss when the in-memory Redis server crashes or reboots:

• RDB (Snapshotting): Flushes compact point-in-time binary snapshots of in-memory state to disk.
• AOF (Append Only File): Logs every write command sequentially to an append-only file on disk.

---

Edge Cases and Misconceptions

Cache Miss Stampede (Thundering Herd)

A common misconception is that adding Redis solves all database bottleneck problems. If a highly-frequented key (like the homepage payload) expires under high traffic, thousands of concurrent requests will experience a cache miss at the exact same millisecond. They will all fall back to query the main database simultaneously, potentially causing a DB crash. Systems solve this using lock locks (like mutexes) or pre-warming caches before TTL expiration.

Asynchronous Replication Loss

Because Redis uses asynchronous replication to keep latency low, writing to the primary and receiving “OK” does not guarantee replication to replica nodes. If the primary crashes before the replication packets reach the replicas, Sentinel will elect a replica as the new primary, resulting in the loss of that write.

Blocking the Single Thread

Since Redis is single-threaded, any command with a complexity of $O(N)$ (where $N$ is large, like KEYS * or KEYS pattern) will block the entire event loop. No other read or write request can be processed until the scan completes. Production systems forbid commands like KEYS and use SCAN instead to query keys incrementally.