Redis & caching

01What Redis actually is

Think of Redis as a giant shared dictionary that lives in RAM. Reading from memory takes microseconds, while a typical database query takes milliseconds, so Redis is often 100 times faster for simple lookups. But Redis is more than key → string. It offers data structures: strings (and counters), hashes (an object with fields), lists (queues), sets (unique members), sorted sets (leaderboards, time-ordered items), streams (an append-only log with consumer groups), plus bitmaps, HyperLogLog and geo indexes. Every command runs atomically on a single main thread, which is why INCR on a counter is safe even with many clients. Licensing note for 2026: Redis 8 is available under AGPLv3 (alongside its source-available licences), and Valkey is a BSD-licensed, Linux Foundation fork that most clouds offer as a drop-in replacement.

• String: cached JSON, counters, flags
• Hash: a user session or a settings object
• List / Stream: job queues and event logs
• Sorted set: rankings, scheduled items, sliding-window rate limits

1SET product:42 '{"name":"Latte","price":1500}' EX 300
2GET product:42
3INCR rate:203.0.113.10:2026-11-05T10:01
4HSET session:abc user_id 7 role cashier
5EXPIRE session:abc 1800
6ZADD leaderboard 980 player:1 1200 player:2
7ZREVRANGE leaderboard 0 9 WITHSCORES
8TTL product:42

02Caching patterns: cache-aside, write-through, write-behind

Cache-aside (lazy loading) is the default: the app asks Redis first; on a miss it reads the database, stores the result with a TTL and returns it. Only data that is actually requested gets cached, and if Redis dies the app still works, just slower. Write-through means every write goes to the database and the cache at the same time, so reads are always warm — good for small, read-heavy data like settings. Write-behind writes to the cache first and flushes to the database later; it is fast but can lose data, so I avoid it for anything financial. Whatever the pattern, the database stays the source of truth. A cache is a copy, and you must be able to delete all of it without losing anything.

1async function getMenu(branchId: string) {
2  const key = `menu:v3:${branchId}`;
3  const hit = await redis.get(key);
4  if (hit) return JSON.parse(hit);
5 
6  const menu = await db.menu.findForBranch(branchId);
7  // TTL with jitter so many keys do not expire at the same moment
8  const ttl = 600 + Math.floor(Math.random() * 60);
9  await redis.set(key, JSON.stringify(menu), "EX", ttl);
10  return menu;
11}
12 
13async function updateMenu(branchId: string, data: MenuInput) {
14  await db.menu.update(branchId, data);
15  await redis.del(`menu:v3:${branchId}`); // invalidate after the write commits
16}

03TTL, invalidation and the cache stampede

There are two ways cached data goes away: it expires (TTL) or you delete it on purpose (invalidation). Use both: invalidate on writes you control, and keep a TTL as a safety net for the writes you forgot. Put a version in key names (menu:v3:…) so a change in data shape never reads old blobs. Delete after the database transaction commits, not before, or a concurrent reader can refill the cache with stale data. A cache stampede (thundering herd) happens when a hot key expires and hundreds of requests miss at once and all hit the database. Fixes: add random jitter to TTLs, let only one request rebuild the value using a short lock (SET key NX EX), serve the stale value while one worker refreshes it, or refresh popular keys ahead of expiry in the background.

1// One rebuilder per key; others wait briefly or serve stale data
2const lock = await redis.set(`lock:${key}`, "1", "NX", "EX", 10);
3if (lock === "OK") {
4  try {
5    const fresh = await loadFromDb();
6    await redis.set(key, JSON.stringify(fresh), "EX", 600);
7  } finally {
8    await redis.del(`lock:${key}`);
9  }
10}

04Sessions, rate limiting and locks

Redis is a natural home for short-lived shared state. Sessions: store the session in a hash with a TTL, so any app server can read it and logging out is a single DEL. Rate limiting: a fixed window is INCR on a key like rate:{ip}:{minute} with EXPIRE; it is simple but allows bursts at window edges. A sliding window uses a sorted set of timestamps, or a token bucket in a small Lua script, for smoother limits. Use the same idea to cap OTP attempts and login failures per phone or account, not only per IP. Locks: SET lock:order:42 token NX EX 30 gives one worker exclusive work for 30 seconds; release it only if the token still matches, otherwise you may delete someone else's lock. For real money, a database constraint or idempotency key is still the final guard.

1-- Fixed-window limit: 100 requests per 60 s, atomic in one call
2-- KEYS[1] = rate key, ARGV[1] = limit, ARGV[2] = window seconds
3local n = redis.call("INCR", KEYS[1])
4if n == 1 then
5  redis.call("EXPIRE", KEYS[1], ARGV[2])
6end
7if n > tonumber(ARGV[1]) then
8  return 0
9end
10return 1

05Queues and pub/sub

Lists and streams make Redis a capable job broker. Libraries such as BullMQ (Node) and Laravel queues (PHP) store jobs in Redis and give you retries with backoff, delays, priorities and dead-letter handling. The web request stays fast because sending an email or syncing with an ERP happens in a worker. Pub/sub is different: a message is broadcast to everyone subscribed right now and is not stored. It is perfect for fan-out of real-time events across several WebSocket servers (socket.io's Redis adapter does exactly this), but if no one is listening the message is gone. When you need delivery guarantees or replay, use Streams with consumer groups or a real queue. Rule of thumb: pub/sub for 'tell everyone now', queues for 'make sure this happens'.

06Persistence, memory and eviction

Redis keeps data in RAM but can save it to disk. RDB writes periodic snapshots: compact and fast to restore, but you lose writes since the last snapshot. AOF (append-only file) logs every write; with appendfsync everysec you lose at most about a second. Many setups use both. For a pure cache, persistence can be off. For queues and sessions, turn AOF on. Always set maxmemory and an eviction policy: allkeys-lru or allkeys-lfu for a cache, noeviction for a queue (you want errors, not silently deleted jobs). Ideally keep the cache and the queue on separate instances or databases with different policies. Never expose port 6379 to the internet: bind to localhost or a private network, require a password or ACL users, and use TLS across networks.

1# /etc/redis/redis.conf (cache + small queue on a private host)
2bind 127.0.0.1
3protected-mode yes
4requirepass change_me_long_random
5maxmemory 1gb
6maxmemory-policy allkeys-lfu
7appendonly yes
8appendfsync everysec
9save 900 1

07When not to cache

Caching adds a second copy of the truth, and every copy can be wrong. Do not cache before you measure: often an index or a fixed N+1 query solves the problem with no new moving parts. Avoid caching data that must be exact at the moment of reading — stock levels at checkout, wallet balances, payment status — or cache it only for display and re-check from the database inside the transaction. Do not cache per-user responses under a shared key (a classic leak of one customer's data to another). Be careful caching things that change on almost every request: the hit rate will be near zero and you pay for the writes. Finally, if the dataset is tiny and the database is idle, an in-process memory cache or HTTP caching headers may be all you need.

08The single thread: why one slow command hurts everyone

Redis executes commands one at a time on its main thread. Since Redis 6, optional I/O threads (io-threads) read and write network sockets in parallel, but the commands themselves still run in sequence. That design is why every command is atomic, and also why one O(N) command stalls every other client. KEYS * on ten million keys, SMEMBERS on a huge set, LRANGE 0 -1 on a long list or DEL on a big hash can block for hundreds of milliseconds, and to the application that looks like a Redis outage. Iterate with SCAN, HSCAN and SSCAN in small batches. Delete big keys with UNLINK, which frees the memory in a background thread. Find offenders before they hurt you: SLOWLOG records commands above a threshold, LATENCY DOCTOR explains spikes, and redis-cli --bigkeys and --memkeys sample the keyspace without blocking it.

1# Find big keys and memory hogs (samples with SCAN, safe in production)
2redis-cli --bigkeys
3redis-cli --memkeys
4 
5# Commands slower than slowlog-log-slower-than (microseconds)
6redis-cli SLOWLOG GET 10
7redis-cli LATENCY DOCTOR
8 
9# Memory health and cache efficiency
10redis-cli INFO memory | grep -E 'used_memory_human|mem_fragmentation_ratio'
11redis-cli INFO stats  | grep -E 'keyspace_hits|keyspace_misses|evicted_keys'
12 
13# Remove one big key without blocking the main thread
14redis-cli UNLINK report:2026:full

09Replication, Sentinel and Cluster

A replica copies the primary asynchronously: the primary answers the client first and ships the write afterwards. If the primary dies just after acknowledging a write, failover can promote a replica that never saw it. The WAIT command blocks until N replicas confirm, which narrows that window but does not make Redis a strongly consistent database. Sentinel watches a primary and its replicas, votes on failure and promotes a replica; clients ask Sentinel where the current primary is. Cluster solves a different problem — data larger than one machine — by splitting the keyspace into 16,384 hash slots spread across several primaries. Multi-key commands, transactions and Lua scripts only work when all keys hash to the same slot, otherwise you get a CROSSSLOT error. Hash tags fix this: only the part inside {braces} is hashed, so related keys land together.

1# Only "user:42" inside the braces is hashed -> same slot
2SET {user:42}:profile '{"name":"Ana"}'
3SET {user:42}:cart '{"items":3}'
4MGET {user:42}:profile {user:42}:cart
5 
6CLUSTER KEYSLOT {user:42}:cart
7# Without a shared hash tag, MGET across slots returns CROSSSLOT

10The race condition every cache-aside system has

Cache-aside has a classic race. Reader A misses the cache and reads the old row. Writer B updates the row and deletes the key. Reader A, slightly slow, now writes the old value back into the cache, where it stays until the TTL expires. Deleting after commit makes the window small, not zero. Several defences, from cheap to strong: keep TTLs short for data where staleness matters; delete again a moment later (delayed double delete) from a queue job; store a version or updated_at with the cached value and refuse to overwrite a newer one, using a small Lua script; or drive invalidation from the database itself with a transactional outbox or change data capture, so no code path can forget it. For very hot reads, Redis client-side caching (CLIENT TRACKING, since Redis 6) lets the server push invalidation messages to application-level near caches.

11Memory internals: eviction, encodings and per-field TTL

Eviction is approximate. Instead of tracking a perfect LRU order, Redis samples a few keys (maxmemory-samples, default 5) and evicts the best candidate; raising the sample size gets closer to true LRU at some CPU cost. LFU keeps a small logarithmic access counter per key that decays over time, so a key that was popular yesterday eventually becomes evictable. Small hashes, lists, sets and sorted sets are stored in compact listpack encodings, which is why many small hashes often use less memory than many separate string keys. Check one key with MEMORY USAGE and watch mem_fragmentation_ratio; active defragmentation (activedefrag yes) can reclaim fragmented memory online. Since Redis 7.4 hash fields can expire individually with HEXPIRE, useful for sessions where an OTP field should vanish after 60 seconds while the session itself lives on. A key-level TTL still removes the whole hash, whatever the field TTLs are.