Redis Architecture: How Redis Works Inside

Redis is a single server process that keeps the whole dataset in memory and executes commands one at a time on a main thread, driven by an event loop that multiplexes every client connection. Around that core sit background threads for slow disk work, optional I/O threads for network reads and writes, compact encodings for small values, two persistence mechanisms, asynchronous replication, and two ways to add failover: Sentinel and Cluster.

This page explains how those parts fit together and what each one means in production. For what teams use Redis for, see what Redis is used for.

Redis's documentation describes a mostly single-threaded design: one process serves all clients through multiplexing and executes requests sequentially. Every command is atomic without locks.

It also sets the main operational rule: a slow command blocks everyone. KEYS * on a large keyspace, a long Lua script or DEL on a huge key holds the main thread until it finishes. Use SCAN, bounded ranges and UNLINK, and watch SLOWLOG.

"Mostly" covers three exceptions that never execute commands:

• Background threads, used since Redis 2.4 for slow disk operations such as the AOF fsync, and since 4.0 for lazy freeing: UNLINK and the lazyfree-lazy-* options release memory off the main thread.
• Forked child processes that write RDB snapshots and rewrite the AOF. The fork itself runs on the main thread and can pause it.
• I/O threads, covered next.

Redis 6.0 added optional threaded I/O, set with io-threads: extra threads wrote replies to sockets, and reading and parsing requests needed io-threads-do-reads as well. Redis 8.0 replaced it with a new implementation in which the threads always handle both reads and writes, and io-threads-do-reads no longer has any effect. In both versions commands still execute on the main thread.

# redis.conf: try 3 threads on a 4-core machine, 7 on 8 cores
io-threads 4

The guidance in redis.conf is to enable threading only on machines with at least four cores, leaving one spare, and only when Redis is using a large share of CPU time. Beyond that, the way to use more cores is more instances or Redis Cluster.

Every value has a type and an internal encoding, visible with OBJECT ENCODING key. Small values use compact encodings; Redis converts them to the general encoding once they grow past the *-max-listpack-entries and *-max-listpack-value thresholds or an operation needs it.

Listpack replaced ziplist in Redis 7.0. Compact encodings take far less memory than hash tables or skiplists; raising the thresholds trades CPU per access for that saving.

The whole dataset lives in RAM, so memory is the capacity limit. On Linux Redis is built with jemalloc by default, chosen because it fragments less than libc malloc. maxmemory caps the dataset and the eviction policy decides what happens at the cap. Redis's administration guide says to leave room for overhead and fragmentation (with 10 GB free, set 8 or 9 GB), and a write-heavy instance can use up to twice its normal memory during a snapshot. The Redis memory guide covers the details.

Redis can write the dataset to disk as RDB snapshots, an append-only file, or both, so a restart does not start empty. Both use a forked child, which is why persistence affects latency and memory. Our Redis persistence guide covers RDB vs AOF, the fsync options and what breaks in production.

Replication is asynchronous. The primary streams its writes to replicas, which are read-only by default, and does not wait for them. Each dataset history has a replication ID, and each byte of the stream advances an offset:

• Partial resync. A replica that reconnects sends its replication ID and offset with PSYNC and receives only what it missed, if the primary's backlog (repl-backlog-size, 1 MB by default) still holds it.
• Full sync. Otherwise the primary forks, produces an RDB snapshot and sends it, then streams the writes buffered meanwhile. Since Redis 7.0 the snapshot goes straight to the socket by default (repl-diskless-sync yes).

WAIT lets a client wait for a number of replicas to acknowledge its writes, but Redis's documentation is explicit that this does not make the system strongly consistent: acknowledged writes can still be lost in a failover.

Replication alone does not fail over. Two built-in options add that:

Choose Sentinel while one node holds the data with headroom, and Cluster when it does not. Our Redis Cluster guide covers hash slots and resharding, and Redis high availability walks through the failover sequence for both.

Valkey forked Redis 7.2.4 in 2024 and kept its architecture. It has since diverged in a few places:

• I/O threading (Valkey 8.0, September 2024). Valkey wrote its own asynchronous model rather than adopting Redis 8's. The main thread hands jobs to I/O threads: reading and parsing commands, writing replies, polling sockets with epoll_wait and freeing memory. It scales the number of active threads with load. Command execution stays single-threaded.
• Dual-channel replication (Valkey 8.0). During a full sync the RDB snapshot travels on a separate connection from the stream of new writes. It is off by default (dual-channel-replication-enabled no).
• A new key table (Valkey 8.1, March 2025). Valkey replaced the main dictionary, and the hash, set and sorted set implementations, with a more memory-efficient hash table.
• Data files. Valkey reads RDB and AOF files from Redis OSS 7.2 and earlier, but not files written by Redis 7.4 and later.

For most applications the protocol and commands are the same. Our Valkey vs Redis comparison covers licensing and feature differences, and Redis end of life lists which Redis versions still receive fixes.

Most Redis incidents trace back to the architecture: a slow command holding the main thread, a fork stalling a large instance, or a full sync looping. AceMQ provides Redis support for open-source Redis and Valkey support for the fork, and Redis managed services if you would rather we run it.

• Redis: Diagnosing latency issues (single-threaded design, fork)
• Redis: Redis 6.0 release notes (threaded I/O)
• Redis: Redis 8.0 release notes (new I/O threading)
• Redis: redis.conf for Redis 8.2 (io-threads guidance, defaults)
• Redis: OBJECT ENCODING (encodings by type)
• Redis: Redis 7.0 release notes (listpack, diskless sync default)
• Redis: README (jemalloc default on Linux)
• Redis: Redis administration (memory sizing)
• Redis: Redis replication
• Redis: High availability with Redis Sentinel
• Redis: Redis Cluster specification
• Valkey: Unlock 1 million RPS (Valkey 8 I/O threading design)
• Valkey: Valkey 8.0 release notes
• Valkey: Valkey 8.1 release notes (new hash table)
• Valkey: Migration from Redis to Valkey