Suggest an editImprove this articleRefine the answer for “Why is Redis considered a single-threaded system?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)Redis is considered single-threaded because every client command runs in one main thread - sequentially, one after another, with no parallel execution of several operations at once; the next command only starts once the previous one finishes. **Key point:** this is a deliberate architectural choice, made for no locking, minimal overhead, and predictability; background threads do exist (for RDB/AOF, replication, I/O), but they don't interfere with command processing, so Redis stays single-threaded in the classic sense.Shown above the full answer for quick recall.Answer (EN)ImageRedis is considered a **single-threaded system**, because **all client commands run in one main thread**, sequentially, one after another, with no parallel execution of multiple operations at once. ### 1. The core idea Redis uses **one main thread** that: - accepts client requests, - executes commands, - sends responses, - manages memory. That means at any given moment, Redis **processes only one command**. The next command only starts **after the previous one finishes**. ### 2. Why single-threading was chosen Single-threading in Redis is a **deliberate architectural choice** for maximum performance and simplicity: 1. **No locking.** Data access doesn't need to be synchronized between threads, which removes mutexes, deadlocks, and the overhead of managing them. 2. **Minimal overhead.** No time is spent switching context between threads. 3. **Predictability.** Redis's behavior is deterministic: commands run strictly in the order they arrive. 4. **High performance through simplicity.** By keeping all data in memory and having no locking, Redis reaches millions of operations per second even in a single thread. ### 3. But Redis isn't entirely "single-core" While **command processing** runs in a single thread, Redis does use **extra background threads** for certain tasks: - saving data to disk (`RDB` and `AOF`), - asynchronous memory freeing, - replication, - disk I/O, - network operations. These processes don't interfere with the main command-execution logic and don't introduce locking. ### 4. The "event loop" model Redis is built on an **event loop model**, similar to Node.js: - a single core, - non-blocking I/O, - connection multiplexing via `epoll`, `kqueue`, or `select`. That's what lets Redis serve thousands of clients simultaneously while staying single-threaded. ### 5. Modern optimizations Newer versions of Redis (starting with 6.0) added **I/O threads**, extra threads that handle only network I/O. But **executing the commands themselves** stays strictly single-threaded, so the sequential-operation model doesn't break. ### 6. Summary Redis is considered single-threaded because: 1. The main thread runs every command sequentially. 2. There's no parallel computation on shared data. 3. Single-threading makes Redis deterministic, fast, and free of locking. Background threads do exist, but they don't take part in processing commands, and they don't make Redis a multi-threaded database in the classic sense.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.