How Redis Achieves High Concurrency with a Single Thread and Its Key Limitations

Q1. How does Redis’s single‑threaded model support high concurrency?

Redis uses the Linux epoll I/O multiplexing facility. A single worker thread sequentially reads network data, parses commands, executes them, and writes responses. Because epoll can monitor thousands of sockets, many client connections are serviced without creating additional threads.

Q2. Does adding CPU cores improve Redis performance?

Before Redis 4.0 the server ran entirely on one core; 2–3 cores were usually sufficient. Starting with Redis 6.0, network read/write is offloaded to a pool of I/O threads while command execution remains single‑threaded. The processing flow is: collect → distribute → collect Thus, allocating more CPU cores can improve the throughput of the I/O threads, but the core command‑execution path still runs on one thread.

Q3. Redis vs. Memcached

Redis is a superset of Memcached. Memcached only supports simple string key‑value operations, while Redis provides rich data structures (lists, sets, sorted sets, hashes, streams, etc.) and many advanced commands. Memcached also has a versioning concept that Redis’s open‑source edition lacks.

Q4. Can Redis be used as a durable database?

Redis offers Append‑Only File (AOF) persistence with three fsync policies:

no‑fsync : rely on the OS cache; fastest but no durability guarantee.

every‑second : fsync once per second; may lose up to one second of writes.

always : fsync after every write; provides strict durability at the cost of latency.

Replication is asynchronous; a master‑slave failover can lose recent writes, so Redis is generally recommended as a cache rather than the primary store for critical data.

Q5. Data‑synchronization options

Redis’s built‑in master‑slave replication works well within a single data center but does not persist data for cross‑region sync. For cross‑region replication, external middleware or custom pipelines (e.g., pulling data from a cloud source and pushing to the target) are advised.

Q6. Security risk of an unauthenticated Redis instance

Without a password, anyone can connect and execute commands that may lead to full system compromise (e.g., loading malicious modules or executing shell commands), which is why password protection is mandatory in production environments.

Q7. Request ordering after Redis 6.0

Within a single client connection, commands are processed sequentially even when network I/O is multithreaded. Across multiple connections, reads and writes can proceed in parallel, but each connection’s command stream preserves order.

Q8. Time complexity of Redis operations

Unlike Memcached’s uniformly O(1) operations, Redis operations vary by data type. Examples include:

String GET/SET – O(1)

List LPUSH/RPOP – O(1)

List LINSERT – O(n)

Set SADD – O(1), SMEMBERS – O(N)

Sorted set ZADD – O(log N), ZRANGE – O(log N + M)

Q9. Latency characteristics

Redis can execute commands in sub‑microsecond (hundreds of nanoseconds) time, but network latency (typically 1–3 ms within the same data center) dominates end‑to‑end response time, making the nanosecond‑level processing invisible to clients.

Q10. Definition of a “big key”

A key is considered “big” when its value size exceeds roughly 1 KB or when it consumes a large amount of memory. Redis instances have a default maxmemory limit of 512 MB, which should be monitored to avoid excessive big keys.