3.1 Redis Execution and Threading Model

1. Event-Driven Architecture

Redis accepts many client sockets through an event-driven I/O loop built on platform readiness mechanisms such as epoll, kqueue, or equivalents.

At a high level:

1. socket readiness events are collected;
2. requests are read and parsed;
3. commands execute against the in-memory dataset;
4. replies are written back to clients.

2. What “Single-Threaded” Historically Meant

The classic Redis design executes commands largely serially on the main server thread. This simplifies shared-state synchronization and gives individual commands atomic execution relative to other commands on that shard.

But Redis as a process is not literally one thread.

Background work can include persistence, asynchronous memory freeing, I/O helpers, and other subsystem tasks.

3. Threaded I/O

Modern Redis can use I/O threads to help read/write client network data while keeping command execution semantics centered on the main execution path.

Therefore, the useful mental model is:

commands on one Redis shard generally do not execute as arbitrary parallel shared-memory mutations, even though networking/background work can use multiple threads.

4. Performance Consequence

A long-running command can delay unrelated client commands handled by the same shard.

Typical causes include:

• O(N) or worse commands on large structures;
• huge payload serialization/deserialization;
• Lua/functions that run too long;
• fork/COW or storage stalls;
• allocator/memory pressure.

This is why big-key and slow-command control matters even when CPU utilization looks low overall.

5. Scaling

To scale command execution across cores, common approaches include:

• multiple Redis instances/shards;
• Redis Cluster;
• application-side partitioning;
• managed proxy/sharding layers.

A single hot key still concentrates work on one owning shard unless the application changes the data model.