How Redis stays fast on a single thread.

Redis is a single-threaded, in-memory data structure server. Salvatore Sanfilippo released it in 2009; the single-threaded design — one event loop processing all commands serially — is the source of its predictable latency and operational simplicity. Redis ships strings, hashes, lists, sets, sorted sets, streams, bitmaps, hyperloglogs, and geospatial indexes as primitive types.

The most surprising fact about Redis is the simplest: there is one thread doing all the command processing. No locks, no atomic ops, no contention. The thread reads from a socket, parses one command, executes it, writes the reply. Then it does the next.

This works because the work each command does is tiny — most are O(1) or O(log n) on small data. A million simple operations per second is achievable on commodity hardware because the path each one walks is short. Multi-threading would add lock contention overhead larger than the work itself.

Below: clients send commands; they queue at the server; the single thread pulls one off, runs it, replies. Trigger an RDB snapshot or watch the AOF log fill alongside.

Redis uses a Reactor pattern: one thread, one event loop on epoll/kqueue. The loop blocks waiting for any connected client socket to be readable. When one is, the thread parses one or more commands from it, runs them, and writes replies. Then back to the loop.

Newer versions split network I/O onto helper threads (the I/O threads), but command execution stays on one thread. The lock-free design persists. Even when Redis "uses multiple threads," the data-structure operations are single-threaded.

Six core data types, each backed by clever encoding decisions. Small strings live inline (embedded inside the object header — no allocation). Small hashes use ziplists rather than hash tables. Sorted sets are skiplists. The right structure for the size, swapped automatically as data grows.

Each type has its own command vocabulary. LPUSH / RPOP for lists turn it into a queue. ZADD / ZRANGEBYSCORE turn sorted sets into leaderboards. XADD / XREAD make streams a tiny Kafka. The data-structure variety is what makes Redis useful for so many things.

Redis is in-memory, but it can survive restarts. Two persistence mechanisms, often used together.

Redis is bounded by RAM. The maxmemory setting caps usage; maxmemory-policy decides what to drop when the cap is hit. Eight policies in modern Redis — LRU, LFU, random, TTL-based — variants for "all keys" vs "keys with TTL set." (See the caching guide for the wider hierarchy.)

The most common production choice is allkeys-lru: when full, drop the least-recently-used key. For workloads with mixed temperature, allkeys-lfu (least-frequently-used) does better. Always set a policy explicitly — the default noeviction rejects writes once memory is full, which is rarely what you want.

A single Redis primary can serve hundreds of thousands of QPS. Beyond that, two scaling shapes: replication for read scale-out, and cluster for write scale-out.

Replication is asynchronous by default — every write is also streamed to replicas. Replicas can serve reads. A primary failure triggers Sentinel-driven failover; one replica is promoted, the rest re-attach.

Cluster shards the keyspace across N primaries via consistent-hash slots (0..16383). Each primary owns a slot range; clients route by hashing the key. Multi-key commands have to stay within a single slot — use hash tags ({user:1}:profile) to force keys onto the same node.

Twitter — timeline cache. Twitter caches user timelines in Redis (sorted sets keyed by user, indexed by tweet ID). Each fan-out write inserts into the followers' timeline sorted sets; reads fetch the top N. The timeline service handles tens of millions of QPS off Redis instances; Postgres / Manhattan handle the durable storage.

Instagram — feed metadata. Instagram's media-metadata cache runs on Redis cluster across thousands of nodes. The hot-path cache hit ratio is reported >99.5%; behind the cache sits Cassandra. Public posts (2020) document the architecture and the years-long migration from a single Redis instance to a sharded cluster.

GitHub — session storage. GitHub keeps user-session state in Redis with replication for failover. The choice was deliberate: the session-write rate is too high for Postgres, too important to lose on a single-node failure. Their 2018 incident postmortem on a 24-hour outage walks through how cross-region Redis replication recovered.

Pinterest — pin counts and rate limiting. Pinterest uses Redis for atomic counter increments (likes, repins) and as a distributed rate limiter. They publicly contributed Redis Cluster proxy improvements upstream.

The single-machine throughput. A single Redis instance hits ~150,000 ops/sec on commodity hardware (single-thread bound). Redis 6's I/O threads brought that to ~400,000. Beyond that, you need Cluster — but cross-shard transactions don't work across slots, so the schema design has to keep related keys on the same hash tag.