Redis
During an IPL final, a fantasy cricket app updates the leaderboard for millions of users after every ball. A relational database would need to re-sort millions of rows each time. Redis does it with one command per user, in well under a millisecond, and returns the top 100 instantly. That is the Redis pitch in one scene: keep the data in memory, in the shape you need it, and make every operation tiny.
Redis is a server that keeps data structures in memory: strings, hashes, lists, sets, sorted sets and more, each with its own fast commands. It is the default answer to caching, rate limiting, sessions, leaderboards and queues, and it shows up in nearly every system design on this site.
Redis handles each command on a single thread, one at a time. That sounds slow. Why is it actually one of the main reasons Redis is fast and easy to use correctly?
How it works inside#
Everything lives in memory. Reading a value is a memory access, not a disk read, which is why a Redis command typically completes in microseconds and a round trip from your app is well under a millisecond on the same network.
One command at a time. Redis executes commands on a single thread, one after another. That
sounds like a limit, and here is the answer to the question above: because nothing runs in
parallel, every command is atomic. INCR views:post:42 from a thousand clients at once
never loses a count, with no locks in your code. Without locks or context switches, one
instance comfortably handles a hundred thousand or more simple commands a second. Newer
versions use extra threads for network I/O, but commands themselves still run one at a time.
Pick the structure, then the command#
The skill in Redis is matching the problem to the right data structure. Flip through the main ones.
Memory is the budget#
Everything is in RAM, so the first capacity question is always how much.
Small values pay a large overhead per key, so millions of tiny keys cost more than you expect. Grouping small related values into one hash, and setting a TTL on anything that is a cache, are the two cheapest ways to keep memory in check. When memory runs out, the maxmemory policy decides: refuse writes, or evict keys (allkeys-lru is the usual choice for a pure cache).
Will I lose data?#
Redis is in memory, so durability is optional and you choose how much you want.
Snapshots (RDB). Every few minutes, Redis forks and writes the whole dataset to a file. Cheap and compact, and a crash loses everything since the last snapshot.
Append only file (AOF). Every write command is appended to a log. With the common setting of flushing to disk once a second, a crash loses at most about a second of writes. Many setups use both.
Replication copies writes to replicas asynchronously, and Redis Sentinel or Redis Cluster promotes a replica if the primary dies. Asynchronous means a write acknowledged by the primary may not have reached the replica yet, so a failover can lose the last few writes.
For caches, sessions, counters and leaderboards that can be rebuilt, losing a second of writes is fine. For money, orders or anything you cannot rebuild, keep the truth in a durable database and let Redis be the fast copy in front of it. The full set of caching patterns is in Caching patterns.
Scaling out: Redis Cluster#
One Redis instance is limited by one machine's memory and one thread. Redis Cluster splits the keys across several primaries using 16,384 hash slots. Each key belongs to one slot, computed as CRC16 of the key modulo 16384, and each primary owns a range of slots. Clients learn the slot map and send each command straight to the right node.
This one runs the real algorithm. Try the presets.
The catch: a command that touches several keys only works if all of them are in the same slot.
user:1000:cart and user:1000:profile hash to different slots. Put the shared part in curly
braces, {user:1000}:cart and {user:1000}:profile, and Redis hashes only the part inside the
braces, so both land together. That is called a hash tag, and it is how you keep one user's
keys transactional in a cluster.
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Single instance with a replica | Simple, every multi key command works, and failover with Sentinel. | Limited to one machine's memory and one command thread. | Most applications. One Redis goes a very long way. |
| Redis Cluster | Memory and throughput scale by adding primaries. | Multi key commands need hash tags, and clients must handle redirects. | When data or traffic outgrows one machine. |
| AOF every second | At most about a second of writes lost in a crash. | More disk I/O and a log that needs rewriting periodically. | When Redis holds data that is painful, but possible, to rebuild. |
In 2024 Redis changed to a more restrictive licence, and the Linux Foundation started an open source fork called Valkey, which many cloud providers now offer. Redis later added an open source licence option again. For design purposes the two behave the same way, and everything on this page applies to both.
Checkpoint#
1. Why is INCR safe when a thousand clients call it on the same key at once?
2. Which structure gives you a live top 100 leaderboard?
3. In Redis Cluster, a transaction on user:1000:cart and user:1000:profile fails with CROSSSLOT. What fixes it?
- In memory, one command at a time: microseconds per command, and every command is atomic.
- Sorted set for rankings, set for membership, hash for objects, INCR for counters.
- AOF every second loses at most about a second. Replication is asynchronous.
- Cluster: 16,384 slots, CRC16(key) mod 16384, hash tags keep keys together.
Redis is an in memory data structure server. It runs commands one at a time on a single thread against data in RAM, so each command takes microseconds and is atomic without locks. The skill is picking the structure: strings with INCR for counters and caches, hashes for objects, lists or streams for queues, sets for membership, sorted sets for leaderboards and sliding windows. Memory is the budget, so I set TTLs and an eviction policy. Durability is optional: snapshots, an append only file flushed every second, and asynchronous replicas, so I keep the source of truth in a durable database. To scale out, Redis Cluster splits keys over 16,384 hash slots, and hash tags keep related keys in one slot.