Recently I have been exploring single-threaded systems, and they are truly amazing. One system that stands out is Redis.
Redis can handle hundreds of thousands of requests per second while using a single thread for command execution. At first glance, that sounds counterintuitive. In practice, it is a deliberate design choice that leads to high performance and simplicity.
Let’s break it down.
What Does “Single-Threaded” Actually Mean?
Redis processes commands using one main thread.
That means:
- Only one command runs at a time
- No parallel execution
- No locks or race conditions
Example
SET user:1 "Aman"
GET user:1
INCR visits
Execution order:
SET → GET → INCR
Each operation is atomic by default.
The Real Secret: Event-Driven Architecture
Redis is not just single-threaded. It is event-driven.
It uses an event loop to handle thousands of connections efficiently.
How It Works
Multiple Clients
↓
[I/O Multiplexing (epoll/kqueue)]
↓
Event Loop
↓
Single Thread Execution
↓
Response to Clients
Request Lifecycle
- Accept connection
- Read request (non-blocking)
- Execute command (single-thread)
- Send response
This cycle repeats extremely fast.
Why Redis is So Fast
1. No Locks, No Context Switching
Multi-threaded systems:
- Require locks (mutex)
- Have context switching overhead
Redis:
- No locks
- No thread switching
More CPU time is spent doing actual work.
2. Everything is in Memory
RAM access ≈ nanoseconds
Disk access ≈ milliseconds
This difference is significant and contributes heavily to performance.
3. Optimized Data Structures
Redis uses:
- Hash tables → O(1)
- Skip lists → O(log N)
Example:
HSET user:1 name "Aman"
HGET user:1 name
These operations are fast because they avoid complex joins and disk lookups.
4. Handles Many Clients via I/O Multiplexing
Redis uses:
- epoll (Linux)
- kqueue (macOS)
This allows it to:
- Handle thousands of connections
- Without creating multiple threads
The Trade-Off: Blocking
Because Redis is single-threaded:
One slow command blocks everything.
Bad Example
KEYS *
- Scans entire database
- Blocks all requests
Better Alternative
SCAN 0 MATCH user:* COUNT 100
- Incremental
- Non-blocking
Is Redis Still Single-Threaded Today?
Not entirely.
Modern Redis (v6+) uses threads for:
- Network I/O
- Background tasks (persistence, cleanup)
However, command execution remains single-threaded.
Real Insight: It’s I/O-Bound, Not CPU-Bound
Most Redis workloads are limited by:
- Network latency
- Not CPU processing
Adding more threads would not significantly improve performance in most cases.
When Should You Use Redis?
Good Use Cases
- Caching
- Session storage
- Real-time analytics
- Leaderboards
Not Ideal For
- Heavy computations
- Long-running operations
- Complex relational queries
Code Example: Redis-Like Server (Conceptual)
const net = require("net");
const server = net.createServer((socket) => {
socket.on("data", (data) => {
const command = parse(data);
const result = execute(command);
socket.write(result);
});
});
server.listen(6379);
This illustrates the event-driven, single-threaded execution model.
Final Takeaway
Redis shows that performance is not about adding more threads, but about designing systems efficiently.
By combining:
- Single-threaded execution
- Event-driven architecture
- In-memory storage
Redis achieves high performance with a simple and predictable model.
Top comments (0)