Data building blocks
Redis specifics
Redis is the default shared cache, and it stores far more than strings. Know its data structures, its single-threaded commands, its eviction settings and how cluster mode splits keys.
Redis is an in-memory key-value store. Most teams use it as a shared cache, and it does far more than hold strings. Its data structures often remove a database query entirely. Its commands are atomic, and a single slow command can block every other client.
Concept
An atomic operation happens completely or not at all, with no half-finished state visible to other clients. A hash slot is one of 16,384 buckets that Redis cluster mode uses to split keys across machines.
The big idea
Redis runs commands on a single thread. That makes each command atomic and simple to reason about. The cost is that one slow command, such as KEYS * on a large keyspace, stops everything else. Keep commands short, and pick the right structure for the job.
Walking through it
Data structures. Redis offers strings, hashes (an object's fields), lists, sets, sorted sets, streams, bitmaps, HyperLogLog and geospatial indexes. Two examples show the value:
- Sorted sets power leaderboards, rate-limit windows and time-ordered feeds.
- HyperLogLog counts distinct values approximately in about 12 KB.
Atomicity. A single command is atomic. MULTI/EXEC and Lua scripts make several commands atomic together.
Persistence. RDB takes periodic snapshots. AOF logs every write. With appendfsync everysec, up to about one second of writes can be lost after a crash. For a pure cache, you may turn both off.
Eviction. The maxmemory-policy setting controls what happens when memory fills.
noevictionis the default. It returns errors once memory is full, which is wrong for a cache.- For a cache, use
allkeys-lruorallkeys-lfu.
Cluster mode. Each key maps to one of 16,384 hash slots, using CRC16(key) mod 16384. Slots spread across primaries, and each primary has replicas. Multi-key commands only work when all keys share a slot. Force that with a hash tag, which is the part in braces:
{user:42}:profile
{user:42}:settings ← same slot, because only "user:42" is hashedMemcached is the simpler alternative. It is multi-threaded and stores only strings, with no persistence or replication. It still wins for very large, simple caches where per-node multi-core throughput matters.
Note
Redis changed its license in 2024, and the Linux Foundation fork Valkey is now a drop-in option from several cloud providers. The design advice here applies to both. Check current licensing before you choose.
Common mistakes
- Using
KEYS *in production. One slow command blocks every client. UseSCAN, which walks the keyspace in small batches. - Leaving
noevictionon a cache. Once memory is full, writes fail instead of old entries being evicted. - Multi-key commands across slots. They fail in cluster mode unless the keys share a hash tag.
Check yourself
- What does
allkeys-lrudo when memory fills? It evicts the least recently used keys, so the cache keeps accepting new writes. - Why does
{user:42}:settingsuse braces? Only the text in braces is hashed, so keys with the same tag land in the same slot and multi-key commands work.
Key takeaways
- Redis is single-threaded, so commands are atomic, and slow commands block everyone.
- Use the right data structure, such as a sorted set for a leaderboard, to avoid database queries.
- For a cache, set an LRU or LFU eviction policy, not
noeviction. - In cluster mode, use hash tags for keys that must be used together.
Further learning
The Redis documentation covers each data structure and command in detail.
Next, read about cache invalidation, the hardest part of keeping a cache correct.
Related
Caching
Where to put a cache, how to read and write through it, how to size it from hit-rate math, and how to keep it from serving stale data or melting down.
Hit rate and sizing
Hit rate sets how much traffic reaches the database. Going from 90% to 99% cuts database load tenfold, so size the cache for the working set and measure hit rate as a capacity metric.
Sharding and partitioning
Split data across machines by choosing a shard key, hashing or ranging it, routing requests, handling hot spots, resharding without downtime and generating IDs that stay unique.