Why and How Is Single-Threaded Redis Fast and Can Handle Multiple Connections? | Redis Internals

Redis overview & why it’s fast

• Redis is an open-source in-memory data store that can act as a database, cache, message broker, and streaming engine.
• It ships with many built-in data structures—hashes, lists, sets, sorted sets, bitmaps, HyperLogLog, geospatial indexes, and streams—enabling use cases like:
  • real-time chat
  • gaming leaderboards
  • session/auth stores
  • media streaming
  • real-time analytics
• Redis’s popularity is attributed to flexibility, and especially simplicity. The speaker claims its adoption trend is exponential.

Core concurrency/consistency claim: atomic commands

• A key highlight: every Redis operation is “atomic.”
• Meaning in the video: while Redis is executing one command, it doesn’t context-switch to run other commands mid-operation.

Examples of atomicity mentioned:

• Setting a key
• Appending/adding to a list
• Set operations like union/intersection
• Incrementing counters
  • Unlike count++ in typical multithreaded code (not thread-safe), Redis guarantees that concurrent increments across multiple TCP clients result in the correct final count.
  • Example: the final value becomes 10 when 10 clients increment concurrently.

Storage model & persistence options

• Primary storage is in memory, which is why Redis is often used as a cache.
• Persistence is configurable, including:
  • Periodic dumping to disk (checkpoint-style), so restarts recover to the last dump.
  • Write-Ahead Logging (AOF): update commands are appended to an append-only file to reconstruct state.
• Persistence can also be disabled entirely if losing data on crash is acceptable.
• Additional reliability mechanism: asynchronous replication to another Redis instance.

Other product features referenced

• Transactions
  • While a transaction executes, other work doesn’t interleave (simplified description from the transcript).
  • Rollback is discussed later (per the transcript).
• Pub/Sub
  • Publishers send to a topic, and all subscribed consumers receive messages (push-based).
• TTL / key expiration
  • Keys can be automatically deleted after a time, useful for:
    • session/auth tokens
    • preventing indefinite growth (“memory leaks”) from stale data
• LRU eviction / key eviction strategy
  • Redis continues serving requests but evicts keys when memory is full, configurable, avoiding manual cache management.

---

How Redis handles many connections with single-threading (main technical tutorial/analysis)

The problem with typical multithreaded approaches

The speaker frames the issue as: handling many clients in a single process requires a concurrency strategy.

Common multithreading model:

• spawn a new thread per client/request
• threads execute concurrently (possibly on different cores)
• requires mutexes/semaphores to protect correctness

Demonstrated correctness problem:

• race conditions like count++
  • two threads may read the same old value
  • both write back the same incremented result
  • can produce an incorrect total (e.g., ending at 11 instead of expected 12)

Proposed “fix” in the multithreaded model:

• pessimistic locking: only one thread enters the critical section at a time; others wait
• downside: unnecessary blocking, reducing throughput

Redis’s alternative: I/O multiplexing + event loop (apparent concurrency)

Redis adopts I/O multiplexing rather than true multithreaded concurrency.

Core concept:

• network I/O is slow, and blocking reads waste CPU if data isn’t ready
• instead of calling read() blindly, Redis uses I/O monitoring (the transcript doesn’t name select/epoll/kqueue, but describes the idea):
  • monitor sockets
  • only read when data is ready

Runtime model described:

• single process, single thread
• an event loop repeatedly:
  1. accept multiple TCP connections
  2. read from sockets that have data available
  3. execute commands immediately (in-memory)
  4. check again for other ready sockets or new incoming connections

This “concurrent” behavior is apparent concurrency: it interleaves across connections without multi-threading.

Why single-threaded Redis can still be fast

Claim: Redis is fast because:

• after receiving commands, operations are mostly in-memory operations (e.g., increment, list updates), which are extremely fast
• network waiting dominates time, but I/O multiplexing avoids blocking on sockets that aren’t ready

Result: Redis can handle many TCP connections while maintaining high throughput, without mutex/semaphore complexity for correctness.

Tutorial progression mentioned

• The speaker says the next video will start building a TCP server in Go and begin the foundation for a Redis-like implementation.

---

Main speakers / sources (from transcript)

• Single speaker/host (no specific name given in the subtitles).
• Primary source discussed: the Redis system (Redis internals; no external reviewer/source referenced in the provided subtitles).