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[App 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

App Servers

Runs the client-side application logic querying for data. Directs read requests to Redis. If a key is missing (cache miss), it queries the Main Database and writes the resulting value back to Redis. In the demo, you can see App Servers dispatching GET requests to Redis, querying the DB on a miss in Step 4, and writing back.

Redis Primary (Primary Instance)

Serves as the single-threaded write coordinator and authoritative copy of data. Processes writes, maintains in-memory key structures, enforces TTLs, and streams replication packets to replicas. In the demo, observe it handling client write commands and coordinating state updates.

Redis Replicas / Shards

Scales read capacity (Replicas) or scales write capacity and partitions memory (Shards).

• Replicas: Maintain read-only copies of the primary instance to handle heavy read traffic.
• Shards: Divide the keyspace into 16,384 logical hash slots, with each cluster node handling a specific range.

In the demo, watch read queries routed to replicas and keys distributed across separate shards in the relevant guided phases.

Main Database

Provides transactional, persistent database storage of record (e.g. PostgreSQL). Handles writes and reads, serving as the source of truth when cache entries are absent. In the demo, you can see the slow Select queries flowing to the database in Step 1.

Disk Storage (AOF & RDB)

Prevents complete data loss when the in-memory server crashes or reboots.

• RDB (Snapshotting): Writes point-in-time binary files to disk.
• AOF (Append Only File): Logs every write command sequentially to a file.

In the demo, look for the persistence phases when memory changes are synced to disk storage.

---

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.