The Many Roles of Redis
Table of contents
The Many Roles of Redis
Redis started as an in-memory key-value store, but today it covers cache, sessions, queues, ranking, distributed locks, and pub/sub all at once.
1. About Redis
Redis (REmote DIctionary Server) was first released by Salvatore Sanfilippo in 2009. It is written in C and processes commands on a single-threaded event loop. A clean protocol (RESP) and rich data structures are frequently mentioned as strengths.
Redis Stack is a distribution that bundles search (RediSearch), JSON, time-series, graph, and probabilistic data structures.
| Event | Year |
|---|---|
| Redis first release | 2009 |
| Redis Cluster | 3.0 (2015) |
| Redis Streams | 5.0 (2018) |
| Redis 7.0 (Functions, ACL v2) | 2022 |
| License change (RSAL/SSPL) | 2024-03 |
| Valkey fork (Linux Foundation) | 2024-03 |
| Redis 8 — AGPLv3 added | 2025 |
2. Data structures
Redis stores a data structure type per key.
| Type | Memo |
|---|---|
| String | Binary-safe string. Also works as a counter (INCR). |
| Hash | Field-value map. One object per key (HSET user:1 name Alice age 30). |
| List | Bidirectional queue (LPUSH/RPOP). Queues, logs, simple messages. |
| Set | Set without duplicates. Intersection and union operations. |
| Sorted Set (ZSet) | Set sorted by score. Ranking, priority queues. |
| Stream | Append-only log. Consumer group support. Plays a role similar to Kafka. |
| Bitmap | Bit operations on top of strings. Attendance, flags. |
| HyperLogLog | Approximate cardinality estimate. Very small memory (about 12KB for billions). |
| Geo | Lat/lon and radius search (Sorted Set based). |
Each type carries its own command family (HGETALL, ZADD, XADD, etc.).
3. Using as a cache
Park serialized values with TTL on a string key.
SET user:42 '{"id":42,"name":"Alice"}' EX 300
The cache-aside pattern is covered in three-layer-cache.
4. Session store
When there are many web server instances, sessions gather in one place. SETEX session:<sid> <ttl> <payload> or a Hash. Session invalidation and forced logout become easy.
5. JWT blacklists and token rotation
JWT itself is stateless, but when forced logout is needed a strategy of placing short-TTL keys in Redis is common (bl:jwt:<jti>). Refresh token rotation also typically writes the currently valid token to Redis and invalidates the old key on rotation (covered in security/01-jwt-rotation).
6. Rate limit, distributed lock, Pub/Sub
Rate limit — INCR + EXPIRE, or a sliding window based on sorted set. The strength is that one place can be checked in distributed environments.
Distributed lock — SET key value NX EX <ttl> acquires only when the key is absent. A limit is the possibility of concurrent ownership during node failures. Redlock was proposed to address this and the correctness debate has continued (the public exchange between Martin Kleppmann and antirez).
Pub/Sub — SUBSCRIBE and PUBLISH. Simple fire-and-forget. For message persistence and replay, use Streams.
7. Using as a queue
Three branches of patterns exist.
- Simple: List
LPUSH/BRPOP. - Reliable: Streams plus consumer group (
XREADGROUP,XACK,XPENDING). - Priority: Sorted Set with the score as processing time (
ZADD,ZRANGEBYSCORE).
The comparison with dedicated queue systems (RabbitMQ, Kafka) is in kafka-when.
8. Key naming conventions
A colon-separated pattern like <namespace>:<type>:<id> is the de facto convention.
user:42 # Hash
user:42:sessions # Set
session:abc123 # String (TTL)
bl:jwt:f9... # blacklist
ratelimit:ip:1.2.3.4 # counter
queue:emails # List
KEYS * is dangerous in production (O(n), blocking). Use SCAN instead.
9. License changes and forks
In March 2024, Redis Inc. announced a transition from BSD 3-Clause to a dual RSAL/SSPL license. It is widely understood as a move to control cloud providers reselling Redis as a managed service. With Redis 8 in 2025, AGPLv3 was added and the burden in some scenarios eased again.
At the same time, Valkey was forked under the Linux Foundation, retaining BSD 3-Clause. Major cloud providers (AWS, Google Cloud, Oracle, etc.) reportedly participate. KeyDB is a fork that adds multi-threading (2019), and Dragonfly is a separate implementation that claims multi-threading plus new data structures while keeping the same protocol (2022).
10. Persistence, cluster, memory policy
Persistence options:
- RDB — periodic snapshots. Disk usage stays small even on large memory instances. Data after the last snapshot may be lost.
- AOF — per-command append log. The loss window depends on
appendfsync. - A hybrid using both is common.
Cluster and replication:
- Master-replica asynchronous replication — for read scaling and failover.
- Redis Cluster — 16384 slots are spread across nodes. Key hash decides location. Multi-key commands work only within the same slot.
- Sentinel — automatic failover for non-cluster setups.
When maxmemory fills up, keys evict according to maxmemory-policy: allkeys-lru, volatile-lru, allkeys-lfu, etc. For pure cache use, allkeys-lru is often picked.
11. Common pitfalls
Single-threaded assumption — when one command takes long, others queue up. KEYS *, large sorts, and large LRANGE impact production.
Missing TTL — keys used as cache without TTL grow memory indefinitely.
Multi-key on cluster — MGET k1 k2 k3 errors when the keys land on different slots. Use a {tag} hash tag to force the same slot.
Pub/Sub's no-loss assumption — messages are dropped when a subscriber briefly disconnects. Use Streams when persistence matters.
Distributed lock correctness — the official documentation states the limits and assumptions. For places with strong transactional meaning, consider DB-level locks or fencing tokens.
Closing thoughts
Redis's strength is covering cache, sessions, queues, and locks with one tool. The small operational surface fits small teams well. That said, piling too much into one instance enlarges a single point of failure, so plan the split point in advance.
Next
- data-pipeline
- kafka-when
References: Redis official docs, Redis data structure guide, Valkey official, Redis Cluster spec, antirez Redlock, Martin Kleppmann's rebuttal.