How Does Redis Execute a Command? Inside Its Event‑Driven Architecture

Redis (Remote Dictionary Server) is an open‑source in‑memory key‑value database widely used for caching, message queues, and session storage, and frequently appears in technical interviews.

Redis Deployment Architectures (Macro View)

Single‑instance mode : a basic deployment with one node, no high‑availability guarantees, suitable for development or non‑critical scenarios.

Master‑Slave replication : data is synchronized from a master to multiple slaves, providing read/write separation, improved read performance, and data redundancy.

Sentinel mode : builds on master‑slave replication by adding monitoring nodes that automatically fail over to a new master when the original master fails, achieving high availability.

Cluster mode : a distributed architecture that shards data across multiple nodes, supports automatic failover and horizontal scaling, ideal for massive data and high‑concurrency workloads.

Redis Core Components (Micro View)

Event‑driven engine : a single‑threaded reactor based on I/O multiplexing (e.g., epoll) that handles network events efficiently.

Command processing layer : parses client commands, validates them, and executes operations such as GET, SET, HSET, supporting various data structures.

Memory management system : uses jemalloc/tcmalloc for allocation, implements eviction policies (LRU, LFU, TTL) to optimize memory usage.

Persistence module :

RDB (snapshot) : periodically writes binary snapshots to disk, fast recovery but may lose recent data.

AOF (append‑only file) : logs every write command, provides higher durability with rewrite compression.

Monitoring & statistics system : exposes metrics such as memory usage, QPS, and command statistics for performance tuning.

Key Terminology

Redis client : programs or tools (e.g., redis‑cli, Jedis, Lettuce) that communicate with Redis via the RESP protocol over TCP (default port 6379).

Event‑driven layer : a single‑threaded Reactor (multi‑threaded I/O added in Redis 6.0) composed of file‑event handlers (epoll/kqueue) and time‑event handlers.

Command layer : converts RESP messages into internal data structures, validates commands, and dispatches them to the appropriate implementation.

Memory allocation/reclamation : replaces the system malloc with jemalloc/tcmalloc and provides eviction strategies (LRU/LFU/random/TTL).

RDB & AOF : persistence strategies ensuring data reliability.

Replication (master‑slave) : provides data redundancy, read/write separation, and fault tolerance.

Sentinel : monitors nodes and automatically promotes a slave to master on failure.

Cluster : sharding mechanism using hash slots and Gossip protocol for horizontal scaling.

Monitoring & statistics : exposes runtime information such as used_memory and commandstats.

Event‑Driven Engine

The core of Redis is its event‑driven reactor. Below is the essential data structure:

<span>// Core data structure: aeEventLoop</span>
typedef struct aeEventLoop {
    int maxfd;                // maximum file descriptor
    aeFileEvent *events;      // registered file events array
    aeTimeEvent *timeEventHead; // linked list of time events
    aeFiredEvent *fired;      // array of fired events
} aeEventLoop;

Event processing follows three steps: registration → multiplexed listening → dispatch.

Two main event types exist:

File events : triggered when a socket becomes readable or writable; handled by functions such as

acceptTcpHandler

or

sendReplyToClient

.

Time events : periodic tasks like

serverCron

, executed every 100 ms (configurable) for key expiration, persistence, replication, and cluster health checks.

Reactor Loop

void aeMain(aeEventLoop *eventLoop) {
    eventLoop->stop = 0;
    while (!eventLoop->stop) {
        aeProcessEvents(eventLoop, AE_ALL_EVENTS|AE_CALL_BEFORE_SLEEP|AE_CALL_AFTER_SLEEP);
    }
}

During each iteration,

aeProcessEvents

polls for ready file and time events, invokes the corresponding callbacks, and then returns the number of processed events.

Connection Handling

When a client connects,

acceptTcpHandler

creates a client object and registers a read handler:

aeMain() → aeProcessEvents() → acceptTcpHandler() → createClient() → connSetReadHandler(conn, readQueryFromClient)

Read events trigger

readQueryFromClient

, which either hands the request to I/O threads (Redis 6.0+) or processes it directly in the main thread.

Command Execution Flow

int processPendingCommandsAndResetClient(client *c) {
    processCommand();          // validation (ACL, memory, cluster)
    call();                    // pre‑execution hooks (monitor/watch)
    c->cmd->proc(c);           // actual command implementation (e.g., setCommand)
    propagate();               // replication / AOF propagation
    addReply();                // queue response for client
}

After execution, the response is placed in

clients_pending_write

. The

beforeSleep

function later distributes pending writes to I/O threads or the main thread, which finally calls

writeToClient

to send the reply.

Multithreaded I/O (Redis 6.0+)

When I/O threads are enabled, read and write tasks are split between the main thread and worker threads. The main thread still performs command execution, while I/O threads handle socket reads/writes and background tasks such as heartbeat transmission in Sentinel mode.

In summary, Redis processes a command by accepting a client connection, registering read events, parsing the RESP request, locating the command implementation in

redisCommandTable

, executing the command logic, propagating changes for replication/AOF, queuing the reply, and finally sending the response back to the client through the event‑driven loop.