Redis Architecture Explained — Why It's So Fast

The speed that changed backend architecture#

Redis isn't just a cache. It's an in-memory data structure store that handles millions of operations per second with sub-millisecond latency. Understanding why it's fast teaches you fundamental computer science.

Why single-threaded beats multi-threaded#

Redis processes commands on a single thread. This sounds like a bottleneck, but it's actually the source of its speed:

• No locks, no context switching — the CPU never wastes time coordinating threads
• No race conditions — every command executes atomically
• CPU cache friendly — single thread keeps data hot in L1/L2 cache
• I/O multiplexing — epoll/kqueue handles thousands of connections without threads

A single Redis instance handles 100,000+ operations per second. The bottleneck is almost always network, not CPU.

Core data structures#

Redis isn't just key-value. Each data structure is optimized for specific access patterns:

Strings — Basic key-value. Counters, flags, serialized objects. O(1) get/set.

Hashes — Field-value maps inside a key. Perfect for objects: user:123 → {name, email, plan}. O(1) field access.

Lists — Doubly-linked lists. Push/pop from both ends in O(1). Great for queues, activity feeds.

Sets — Unique collections. Add, remove, membership check in O(1). Intersections and unions for tag-based queries.

Sorted Sets — Sets with scores. Leaderboards, priority queues, time-series data. O(log n) insert, O(1) rank lookup.

Streams — Append-only log. Event sourcing, message queues with consumer groups. Like Kafka, but simpler.

Memory management#

Everything lives in RAM. Redis uses several strategies to manage memory:

• Active expiration — background task randomly samples keys with TTL, deletes expired ones
• Lazy expiration — checks TTL on access, deletes if expired
• Eviction policies — when memory is full: LRU, LFU, random, or volatile-* variants
• Memory-efficient encoding — small hashes use ziplist, small sets use intset

Persistence: RDB vs AOF#

Redis is in-memory but can persist to disk:

RDB (snapshots): Point-in-time dumps at configurable intervals. Fast restarts, but you lose data since last snapshot.

AOF (append-only file): Logs every write command. Three sync policies:

• always — fsync every command (safest, slowest)
• everysec — fsync once per second (good balance)
• no — let OS decide (fastest, riskiest)

Hybrid: Use both. RDB for fast restarts + AOF for minimal data loss.

Scaling patterns#

Replication#

Primary-replica topology. Primary handles writes, replicas handle reads. Async replication — replicas may lag slightly.

Sentinel#

Automatic failover. Monitors primary, promotes a replica if primary fails. Handles service discovery so clients find the new primary.

Cluster#

Sharding across multiple nodes. 16,384 hash slots distributed across primaries. Clients route to the correct shard using the key's hash slot.

Key: "user:123"
Hash: CRC16("user:123") % 16384 = 5649
Shard: Node B (slots 5461-10922)

Common use cases#

When NOT to use Redis#

• Primary database — no complex queries, joins, or transactions across keys
• Large values — anything over 1MB per key degrades performance
• Data larger than RAM — Redis doesn't do disk-based storage well
• Strong consistency requirements — replication is async by default

Visualize your cache layer#

See how Redis fits into a production architecture — try Codelit to generate an interactive diagram showing how your cache layer connects to app servers, databases, and message queues.

Key takeaways#

1. Single-threaded is a feature — no locks, no context switching
2. Choose the right data structure — sorted sets for leaderboards, streams for events
3. Persistence is a trade-off — RDB for speed, AOF for safety, both for balance
4. Cluster for scaling writes — replication only scales reads
5. Redis is not a database replacement — it's a speed layer on top of your primary store