Redis data structure patterns, caching strategies, distributed locks, rate limiting, pub/sub, and connection management for production applications. Use when adding caching, a distributed lock, rate limiting, or pub/sub with Redis, or when key design needs review.

Redis Patterns Quick reference for Redis best practices across common backend use cases. How It Works Redis is an in memory data structure store that supports strings, hashes, lists, sets, sorted sets, streams, and more. Individual Redis commands are atomic on a single instance; multi step workflows require Lua scripts, MULTI/EXEC transactions, or explicit synchronization to stay atomic. Data is optionally persisted via RDB snapshots or AOF logs. Clients communicate over TCP using the RESP protocol; connection pools are essential to avoid per request handshake overhead. When to Activate Adding caching to an application Implementing rate limiting or throttling Building distributed locks or coordination Setting up session or token storage Using Pub/Sub or Redis Streams for messaging Configuring Redis in production (pooling, eviction, clustering) Data Structure Cheat Sheet Use Case Structure Example Key Simple cache String product:123 User session Hash session:abc Leaderboard Sorted Set scores:weekly Unique visitors Set visitors:2024 01 01 Activity feed List feed:user:456 Event stream Stream events:orders Counters / rate limits String (INCR) ratelimit:user:123 Bloom filter / HLL HyperLogLog hll:pageviews Core Patterns Cache Aside (Lazy Loading) Write Through Cache Cache Invalidation Session Storage Rate Limiting Fixed Window (Simple) Sliding Window (Lua — Atomic) Distributed Locks Distributed Lock (Single Node — SET NX PX) For multi node setups use the redlock py library which implements the full Redlock algorithm. Pub/Sub & Streams Pub/Sub (Fire and Forget) Redis Streams (Durable Queue) Prefer Streams over Pub/Sub when you need delivery guarantees, consumer groups, or replay. Key Design Naming Conventions TTL Strategy Data Type Suggested TTL User session 24h ( 86400 ) API response cache 5–15 min Rate limit window Match window size Short lived tokens 5–10 min Leaderboard 1h–24h Static/reference data 1h–1 week Always set a TTL. Keys without TTL accumulate indefinitely and cause memory pressure. Connection Management Connection Pooling Cluster Mode Sentinel (High Availability) Eviction Policies Policy Behavior Best For noeviction Error on write when full Queues / critical data allkeys lru Evict least recently used General cache volatile lru LRU only among keys with TTL Mixed data store allkeys lfu Evict least frequently used Skewed access patterns volatile ttl Evict soonest to expire Prioritize long lived data Set via redis.conf : maxmemory policy allkeys lru Anti Patterns Anti Pattern Problem Fix Keys with no TTL Memory grows unbounded Always set TTL KEYS in production Blocks the server (O(N)) Use SCAN cursor Storing large blobs ( 100KB) Slow serialization, memory pressure Store reference + fetch from object store Single Redis for everything No isolation between cache & queue Use separate DBs or instances Ignoring connection pool limits Connection exhaustion under load Size pool to workload Not handling cache miss stampede Thundering herd on cold start Use locks or probabilistic early expiry FLUSHALL without thought Wipes entire instance Scope deletes by key pattern Cache Miss Stampede Prevention Note: for multi process deployments, replace the in process lock with acquire lock / release lock from the Distributed Locks section above. Examples Add caching to a Django/Flask API endpoint: Use cache aside with setex and a 5 minute TTL on the response. Key on the request parameters. Rate limit an API by user: Use fixed window with pipeline(transaction=True) for low traffic endpoints; use sliding window Lua for accurate per user throttling. Coordinate a background job across workers: Use acquire lock with a TTL that exceeds the expected job duration. Always release in a finally block. Fan out notifications to multiple subscribers: Use Pub/Sub for fire and forget. Switch to Streams if you need guaranteed delivery or replay for late consumers. Quick Reference Pattern When to Use Cache aside Read heavy, tolerate slight staleness Write through Strong consistency required Distributed lock Prevent concurrent access to a resource Sliding window rate limit Accurate per user throttling Redis Streams Durable event queue with consumer groups Pub/Sub Broadcast with no delivery guarantees needed Sorted Set leaderboard Ranked scoring, pagination HyperLogLog Approximate unique count at low memory Related Skill: postgres patterns — relational data patterns Skill: backend patterns — API and service layer patterns Skill: database migrations — schema versioning Skill: django patterns — Django cache framework integration Agent: database reviewer — full database review workflow

redis-patterns