| name | redis-patterns |
| version | 1.0.0 |
| description | Redis caching, TTLs, key design, distributed locks, streams, pub/sub, rate limiting, invalidation, observability, and production reliability patterns. |
| author | skillregistry |
| license | MIT |
| agents | ["cursor"] |
| categories | ["database","backend"] |
| tags | ["redis","cache","streams"] |
Redis Patterns
Use Redis for bounded, operationally safe ephemeral data: caches, rate limits, queues/streams, pub/sub fanout, locks, and session-adjacent state. Do not treat Redis as a silent source of truth unless persistence and recovery are designed.
Workflow
- Decide the data role: cache, coordination, queue, session, or primary store.
- Define key names, TTLs, cardinality, and memory bounds.
- Use atomic commands or Lua/functions for multi-step invariants.
- Add invalidation strategy before caching writes.
- Test expiration, eviction, retries, and failover behavior.
- Monitor memory, key count, latency, hit rate, and rejected connections.
Patterns
const key = `session:${sessionId}:summary`;
const cached = await redis.get(key);
if (cached) return JSON.parse(cached);
const value = await loadSummary(sessionId);
await redis.set(key, JSON.stringify(value), { EX: 300 });
return value;
rate:user:{userId}:messages -> INCR + EXPIRE in one Lua script
lock:job:{jobId} -> SET value NX PX 30000
stream:gateway-events -> XADD / XREADGROUP
Rules
- Every cache key gets a TTL unless there is an explicit reason not to.
- Include version prefixes in keys when payload schemas change.
- Avoid unbounded keys, lists, sets, and streams.
- Use Redis Streams for durable-ish work queues; Pub/Sub is fire-and-forget.
- Use
SET NX PX with unique lock values and safe release checks for locks.
- Do not cache authorization decisions without short TTL and invalidation.
- Monitor eviction policy; unexpected evictions are correctness bugs for some uses.
Verification
redis-cli PING
redis-cli --scan --pattern 'session:*' | head
redis-cli INFO memory
redis-cli SLOWLOG GET 10
Resources
Principles
- Redis data must be bounded.
- TTLs are part of the schema.
- Cache invalidation must be designed with writes.
- Pub/Sub is not a queue.
- Atomicity belongs in Redis commands/scripts, not client timing.