redis/redis

For developers, who are building real-time data-driven applications, Redis is the preferred, fastest, and most feature-rich cache, data structure server, and document and vector query engine.

12 hidden assumptions · 9-stage pipeline · 8 components

Hidden Assumptions

Most of what this code assumes is routine. These 3 are the ones most likely to cause trouble here. The rest are minor; they're under "Show everything".

Open the standalone hidden-assumptions report for redis →

How Data Flows Through the System

Data enters Redis through TCP client connections as command strings, gets parsed into command arguments, validated and executed against in-memory data structures, with responses sent back to clients. Background processes periodically persist data to disk via RDB snapshots or AOF logging, while expired keys are actively and passively cleaned up.

1. Accept client connection — The event loop calls acceptTcpHandler when new TCP connections arrive, creating a client struct and adding the socket to the event loop for read events
2. Read query buffer — readQueryFromClient reads incoming bytes into client->querybuf (sds string), accumulating partial commands until complete RESP protocol messages are received [client → client]
3. Parse commands — processInputBuffer parses the query buffer into argc/argv format, splitting RESP arrays into individual string arguments and storing them as robj pointers in client->argv [client → client]
4. Execute command — processCommand looks up the command in the command table, validates permissions and argument count, then calls the command's proc function (like setCommand, getCommand) with the client context [client → redisObject]
5. Modify data structures — Command handlers like setCommand call dbAdd/dbOverwrite to store robj values in the database dict, while getCommand calls lookupKey to retrieve values, with all operations going through the redisDb hash tables [redisObject → redisObject]
6. Generate response — Command handlers call addReply functions to build RESP protocol responses in client->reply list, with responses like +OK, -ERR messages, or bulk string data [redisObject → client]
7. Send response — sendReplyToClient writes accumulated response data from client->reply to the TCP socket during writable events, handling partial writes and flow control [client]
8. Persist to AOF — propagate calls feedAppendOnlyFile for write commands, serializing the command and arguments to the AOF file for durability and replication [redisCommand]
9. Create RDB snapshot — rdbSaveBackground forks a child process that calls rdbSave to iterate through all databases and serialize every key-value pair to a binary RDB file [redisDb]

Data Models

The data structures that flow between stages — the contracts that hold the system together.

System Behavior

How the system operates at runtime — where data accumulates, what loops, what waits, and what controls what.

Data Pools

Feedback Loops

• Client backpressure (backpressure, balancing) — Trigger: Client output buffer exceeds limits. Action: Pause command processing and close slow clients. Exit: Buffer size returns to normal.
• Memory eviction (auto-scale, balancing) — Trigger: Memory usage exceeds maxmemory limit. Action: Evict keys using LRU/LFU algorithms until under threshold. Exit: Memory usage drops below limit.
• AOF rewrite (self-correction, balancing) — Trigger: AOF file size exceeds configured growth threshold. Action: Fork background process to rewrite AOF with minimal command set. Exit: New AOF file replaces old one.
• Expired key cleanup (polling, balancing) — Trigger: Timer events or key access. Action: Randomly sample keys with TTL and delete expired ones. Exit: Continuous background process.

Delays

• RDB background save (async-processing, ~Seconds to minutes depending on dataset size) — Child process serializes data while parent continues serving clients
• AOF fsync (eventual-consistency, ~System-dependent disk sync time) — Write commands may be lost if system crashes before fsync completes
• Client timeout (cache-ttl, ~Configurable client-timeout seconds) — Idle clients are closed to free resources
• Key expiration (cache-ttl, ~Per-key TTL values) — Keys become inaccessible after expiration time passes

Control Points

• maxmemory (threshold) — Controls: Memory usage limit that triggers eviction policies
• save configuration (threshold) — Controls: RDB save intervals based on time and number of changes
• appendonly (feature-flag) — Controls: Whether AOF persistence is enabled
• timeout (threshold) — Controls: Client idle timeout before automatic disconnection
• tcp-keepalive (threshold) — Controls: TCP keepalive interval for detecting dead clients

Technology Stack

Key Components

• aeEventLoop (orchestrator) — Core event loop that coordinates I/O events, time events, and before-sleep hooks using epoll/kqueue/select src/ae.c
• processCommand (processor) — Central command processor that validates, authenticates, and dispatches Redis commands to their specific handlers src/server.c
• dictCreate (factory) — Creates hash table instances used throughout Redis for key storage, client tracking, and internal data structures src/dict.c
• rdbSave (serializer) — Serializes the entire Redis dataset to a binary RDB file for persistence and replication src/rdb.c
• aofRewrite (serializer) — Reconstructs AOF file by generating minimal command sequence to recreate current dataset state src/aof.c
• redisAsyncContext (adapter) — Manages asynchronous Redis client connections with callback-based command execution and event loop integration deps/hiredis/async.c
• moduleLoadFromQueue (loader) — Dynamically loads Redis modules from shared libraries, registering their commands and data types with the server src/module.c
• zmalloc (allocator) — Memory allocation wrapper that tracks Redis memory usage and integrates with jemalloc for optimized memory management src/zmalloc.c

Related Repository Repositories

Frequently Asked Questions

Analyzed on April 20, 2026 by CodeSea. Written by Karolina Sarna.