Topic 15.1
The Redis Pattern Catalogue and Anti-Patterns
In one line
About thirty named patterns cover almost every Redis design: caching (aside, through, behind, double delete, warming, stampede, penetration, avalanche, negative, multi-level, near-cache), coordination (locks, fencing, idempotency, dedup, leader lease), counting and limiting, queues and scheduling, leaderboards, sessions, pub/sub and streams. Equally important are the anti-patterns that cause most Redis incidents.
Think of it like this
A chef's repertoire. Great cooks don't invent every dish; they know a few dozen techniques (braise, emulsify, reduce) and combine them. Knowing the named Redis patterns lets you assemble a design quickly and communicate it in one sentence.
Key ideas
- 01
Caching patterns: cache-aside, read-through, write-through, write-behind, delete-after-commit (plus delayed double delete), versioned writes, cache warming, stampede prevention (lock, coalescing, stale-while-revalidate, XFetch), penetration prevention (validation, negative cache, Bloom filter), avalanche prevention (jitter, warming), local + Redis multi-level, client-side caching with tracking.
- 02
Coordination patterns:
SET NX PXlock with token and safe unlock, fencing tokens, idempotency keys, dedup claims, leader lease with renewal. - 03
Counting and limiting: atomic counter, sharded counter, buffered counter, HyperLogLog uniques, bitmap activity, fixed/sliding window, token bucket, GCRA.
- 04
Data flow: delayed queue (sorted set by time), priority queue (sorted set by priority, or several lists), reliable list queue (
LMOVE), stream with consumer groups and DLQ, Pub/Sub notification, event stream catch-up, distributed scheduler. - 05
Structures as features: leaderboard (sorted set), session store (hash + TTL + user index), presence (sorted set by last seen), geo search, tag index (sets), secondary index (Query Engine), semantic cache (vectors).
- 06
Anti-patterns: Redis as the only copy of important data without durability planning; Redis as a permanent event store; a lock for everything (and locks without fencing for correctness); queues without acks or DLQs; huge values or unbounded collections; keys without TTLs;
KEYS,SMEMBERS,HGETALL,LRANGE 0 -1on big data;DELon huge keys instead ofUNLINK; one shared instance for cache and critical state; broad hash tags; no client timeouts; relying onSELECTdatabases for isolation.
Code & diagrams
Interview problem
The problem
Review a Redis design
A team's design: one Redis instance (no persistence, allkeys-lru) holds the product cache, user sessions, payment idempotency keys and a job queue implemented with LPUSH/BRPOP. Workers use KEYS job:* to find stuck jobs. Review it and list the fixes in priority order.
Explain it without notes
Name five Redis anti-patterns and the fix for each.
Practice
Audit a Redis deployment you know against the anti-pattern list and write the top three fixes.
Trade-offs
- ↔
Named patterns speed up design and communication, but each still needs its failure behaviour stated for your context.
Done when you can
I can name and apply the core Redis patterns.
I can spot the common anti-patterns in a design review.