← Back to index

Redis — Internal Architecture

A developer's guide to how Redis actually works under the hood: the single-threaded event loop, the data structures and their encodings, the RESP protocol, expiry and eviction, persistence, replication, and how it scales out with Sentinel and Cluster.

Redis is an in-memory data structure server. Unlike a traditional database that keeps data on disk and caches hot pages in memory, Redis keeps the entire dataset in RAM and treats disk only as a durability backstop. Its second defining choice is that command execution is single-threaded: one logical thread runs commands one at a time, which removes locks and makes every individual command atomic. Those two decisions — memory-resident data and a single-threaded execution model — explain almost everything else about how Redis behaves, from its microsecond latencies to the way it persists, replicates, and shards. This guide walks through the internals a developer needs to reason about Redis confidently.

1. Design Goals and Core Ideas

Every internal decision in Redis traces back to a small set of goals. Keeping them in mind makes the rest of the architecture predictable.

2. Architecture and the Event Loop

At its core Redis is a single process running an event loop. It uses the operating system's efficient I/O readiness mechanism (epoll on Linux, kqueue on BSD/macOS) to wait for many client sockets at once and wake up only when one of them has data ready. There is no thread per connection; one thread multiplexes thousands of clients.

One iteration of the loop does the following:

• Poll for readiness: epoll_wait() returns the set of file descriptors that have data to read or room to write. Redis registers a callback per event type.
• Read and parse: for a readable client socket, Redis reads the bytes and parses the RESP request into a command plus arguments.
• Dispatch and execute: the command name is looked up in the command table and executed against the keyspace. Because this happens on one thread, the command runs to completion with nothing else touching the data — that is the source of atomicity.
• Build and queue the reply: the result is serialized into RESP and queued on the client's output buffer, to be written when the socket is writable.
• Run background work: the loop also fires time events — active expiration, incremental rehashing, client timeouts, and similar housekeeping.

I/O threads (Redis 6.0+). Profiling showed that on busy servers a large share of CPU was spent in the kernel reading request bytes and writing reply bytes, not in executing commands. Redis 6 added an optional pool of I/O threads that parallelize only the socket read/parse and reply-write steps. The actual command execution remains single-threaded, so atomicity and the no-locks model are preserved while throughput on multi-core machines improves.

while server_running:
  events = epoll_wait(fds)            # block until sockets ready
  for fd in events.readable:
    buf = read(fd)                    # (optionally on an I/O thread)
    cmd, args = parse_resp(buf)
    reply = dispatch(cmd, args)       # executes on the MAIN thread, atomically
    queue_output(fd, reply)
  for fd in events.writable:
    write(fd, output_buffer[fd])      # (optionally on an I/O thread)
  run_time_events()                   # expiry, rehashing, timeouts

3. Data Structures and Internal Encodings

Redis exposes a handful of data types — string, list, hash, set, sorted set, and stream — but each type can be stored internally in more than one way. Redis picks a compact encoding when a value is small and transparently upgrades to a general encoding once it grows past a configurable threshold. The command behavior is identical; only memory layout and performance characteristics change.

The key encodings are:

4. RESP Protocol and Command Flow

Clients talk to Redis using RESP (REdis Serialization Protocol) — a simple, line-oriented, binary-safe protocol that is easy to parse and human-readable on the wire. A request is an array of bulk strings: the command name followed by its arguments. The reply is a single RESP value whose type depends on the command.

RESP uses a one-byte type prefix to tell the parser what follows:

The full flow for a single command is short, which is the point — minimal per-command overhead:

# Client sends: SET foo bar  ->  *3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\nbar\r\n
function handle_request(socket):
  bytes = socket.read()
  argv  = parse_resp(bytes)            # ["SET", "foo", "bar"]
  cmd   = command_table.lookup(argv[0])
  if cmd is None:
    return reply_error("unknown command")
  if not cmd.arity_ok(argv):
    return reply_error("wrong number of arguments")
  result = cmd.proc(argv)              # mutate the keyspace, atomically
  return encode_resp(result)           # "+OK\r\n"

Pipelining falls out of this design for free: a client may send many requests back to back without waiting for each reply. Redis reads them all, executes them in order, and sends the replies in order, which amortizes network round-trip time across many commands. MULTI/EXEC transactions go one step further by queuing commands and executing the whole batch as one uninterrupted unit on the single thread.

5. Expiry and Eviction

Two different mechanisms reclaim memory, and they solve two different problems. Expiry removes keys whose TTL has elapsed. Eviction removes keys (whether or not they have a TTL) when the server is at its memory limit and needs room for a new write.

Expiration: lazy plus active

Redis never scans every key to check TTLs — that would be far too expensive. Instead it combines two strategies:

• Lazy expiration: when a key is accessed, Redis checks its TTL first. If it has expired, the key is deleted on the spot and the command behaves as a miss. This guarantees you never read a stale value.
• Active expiration: a background cycle (roughly ten times per second) samples a batch of keys that have a TTL, deletes the expired ones, and — if more than about a quarter of the sample turned out to be expired — repeats immediately. This probabilistic sweep keeps expired-but-untouched keys from accumulating in memory.

Eviction: maxmemory policies

When maxmemory is set and a write would exceed it, Redis evicts keys according to the configured policy before accepting the write. LRU and LFU are approximations: rather than maintaining a globally ordered list (expensive), Redis samples a handful of keys and evicts the best candidate from the sample, which is close to true LRU/LFU at a fraction of the cost.

6. Persistence: RDB and AOF

Because data lives in RAM, a restart loses everything unless it has been written to disk. Redis offers two persistence mechanisms with different trade-offs, and a hybrid that combines them.

RDB: point-in-time snapshots

An RDB snapshot is a compact binary dump of the whole dataset at a moment in time. To take one without blocking, the parent process calls fork(). The child inherits a copy of the parent's memory and writes the snapshot to dump.rdb, while the parent keeps serving clients. This is cheap because of the operating system's copy-on-write: parent and child share the same physical memory pages, and a page is only duplicated when one of them writes to it. The snapshot the child sees is therefore consistent and frozen, even as the parent continues mutating data.

RDB files are small and load quickly, which makes them ideal for backups and fast restarts. The downside is the window of loss: anything written since the last snapshot is gone if the process dies.

AOF: append-only file

The Append Only File logs every write command as it is executed. On restart, Redis replays the log to reconstruct the dataset. How much you can lose depends on the fsync policy:

Because the AOF grows without bound, Redis periodically performs an AOF rewrite: it forks a child that writes a new, minimal log representing the current dataset (for example collapsing a hundred increments into a single SET), again using copy-on-write so the parent is not blocked.

Hybrid RDB + AOF

Modern Redis defaults to a hybrid format: an AOF rewrite begins with an RDB-format preamble (the compact snapshot) followed by an AOF tail of the commands that arrived during and after the rewrite. This gives the fast loading of RDB with the small loss window of AOF — the best of both.

# RDB snapshot (non-blocking via fork + copy-on-write)
function save_rdb():
  pid = fork()
  if pid == 0:                         # child
    write_snapshot_to("dump.rdb")      # sees frozen, consistent memory
    exit()
  # parent keeps serving; COW copies a page only when written

# AOF on every write
function on_write(cmd):
  apply(cmd)
  aof_buffer.append(serialize(cmd))
  # flushed to disk per the fsync policy (always / everysec / no)

7. Replication

Redis replication is asynchronous and leader-based: one master accepts writes and streams them to one or more replicas, which serve read-only copies. A master does not wait for replicas to acknowledge before replying to the client, which keeps write latency low at the cost of a small replication lag.

The synchronization protocol is PSYNC, which supports two paths:

• Full resync. Used on first contact or when a replica has fallen too far behind. The master produces an RDB snapshot (forking as in persistence), sends it to the replica, and meanwhile buffers every new write so it can stream them once the snapshot transfer finishes. The replica loads the RDB, then applies the buffered stream.
• Partial resync. Used when a replica briefly disconnects and reconnects. Each master keeps a replication backlog — a fixed-size ring buffer of the most recent write stream — and tracks a replication offset, the number of bytes streamed so far. The replica reconnects citing its last offset and the master's replication ID; if those bytes are still in the backlog, the master replays only the gap. This avoids a full snapshot for a transient blip.

After either path, the master simply keeps streaming each new write command to its replicas as it executes them. Replicas can themselves have sub-replicas (chained replication), forming a tree that offloads fan-out from the master.

# replica connects (or reconnects) to its master
function replica_sync(master):
  send(master, "PSYNC " + known_replid + " " + last_offset)
  resp = recv(master)
  if resp == "FULLRESYNC":
    rdb = recv_rdb(master)             # master forked + snapshotted
    load_into_memory(rdb)
    last_offset = resp.offset
  else:                                # CONTINUE -> partial resync
    pass                               # keep current data; just resume
  while connected:
    cmd = recv_stream(master)          # async stream of writes
    apply(cmd)
    last_offset += len(cmd)

8. High Availability and Scale

Replication by itself gives you read scaling and a warm copy, but a human still has to react when the master dies, and the whole dataset must fit on one machine. Redis solves the first problem with Sentinel and the second with Cluster.

Sentinel: automatic failover

Sentinel is a separate process (run in odd numbers, typically three or five, for quorum) that monitors a master and its replicas. When enough sentinels agree the master is unreachable, they elect a leader among themselves, promote a suitable replica to master, reconfigure the other replicas to follow it, and tell clients where the new master is. Sentinel provides high availability but not sharding — the entire dataset still lives on one master at a time.

Cluster: sharding the keyspace

Redis Cluster partitions the keyspace across many master shards. The mechanism is a fixed map of 16384 hash slots. Every key is assigned to a slot by CRC16(key) mod 16384, and every slot is owned by exactly one shard. To distribute data you simply distribute slot ownership; each shard typically also has replicas for HA, so Cluster folds in the Sentinel-style failover too.

Resharding moves slots from one shard to another online, key by key, while the cluster keeps serving traffic. The combination of a fixed slot count, deterministic CRC16 hashing, and MOVED/ASK redirects lets the cluster rebalance without a coordinator and without taking the keyspace offline.

# client-side routing in a Redis Cluster
function cluster_route(key):
  slot = crc16(hash_tag(key)) % 16384  # {tag} forces co-location
  node = slot_map[slot]                # cached topology
  resp = send(node, command)
  if resp.is_moved():                  # wrong shard, topology changed
    slot_map[resp.slot] = resp.addr    # update cache
    return send(resp.addr, command)
  if resp.is_ask():                    # slot mid-migration
    return send(resp.addr, ASKING + command)  # one-shot redirect
  return resp

9. Summary

The whole system is built from a few reinforcing ideas: