Reference · Cheat sheet

The single-threaded model

The compressed essence. Print it, pin it.

From lesson 0001See also glossary

Fact	So what
Commands execute one at a time on one thread, via an event loop (epoll/kqueue).	Thousands of clients, one queue. No parallel command execution.
Each command is atomic by construction.	No locks needed for a single op. `INCR` can't lose updates.
CPU is rarely the bottleneck; memory + network are.	One instance won't use extra cores. Scale out with shards / Cluster.
A slow command blocks every client (head-of-line blocking).	Big-O = how long you hold the whole server hostage.
"Single-threaded" = command execution only.	Persistence (fork), lazy-free, and 6.0+ threaded I/O run off-thread.

Command complexity — read it as latency

Command	Complexity	Verdict
`SET` / `GET` / `HSET`	O(1)	Safe anywhere.
`ZADD` / `ZSCORE`	O(log N)	Cheap even on huge sorted sets.
`LRANGE` / `SMEMBERS`	O(S+N)	Scales with size returned — bound it.
`KEYS *`	O(N) over all keys	Never in production. Use `SCAN`.
`DEL bigkey`	O(N) elements	Prefer `UNLINK` (frees off-thread).

Rules of thumb

Iterate, don't enumerate: SCAN / HSCAN / SSCAN / ZSCAN over KEYS / SMEMBERS.
Free big keys off-thread: UNLINK over DEL.
Bound every read: page large collections; no LRANGE 0 -1 on unbounded lists.
Check the docs' complexity field before shipping an unfamiliar command — it's on every redis.io command page.
Diagnose spikes with redis-cli --latency and the SLOWLOG.

Common mistake

Treating time complexity as trivia. On a shared single thread an O(N) command is a server-wide stall, not just a slow response to one caller. Complexity is a latency budget.

← lesson 0001 · Source: Redis Docs — Benchmarks