Guide

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.

  • noeviction is the default. It returns errors once memory is full, which is wrong for a cache.
  • For a cache, use allkeys-lru or allkeys-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 hashed

Memcached 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. Use SCAN, which walks the keyspace in small batches.
  • Leaving noeviction on 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

  1. What does allkeys-lru do when memory fills? It evicts the least recently used keys, so the cache keeps accepting new writes.
  2. Why does {user:42}:settings use 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.