| name | redis |
| description | Redis architecture and system design. |
Activate When
/godmode:redis, "design a cache", "redis cluster"
- "pub/sub", "rate limiting", "session store"
- "leaderboard", "Lua scripting", "redis streams"
- "redis caching", "tune redis", "redis cache"
Workflow
1. Use Case Assessment
redis-cli INFO server | grep redis_version
redis-cli INFO memory | grep -E \
"used_memory_human|maxmemory_human|maxmemory_policy"
redis-cli INFO stats | grep keyspace_hit
Version: Redis 6|7|8|Valkey 7+
Hosting: self-managed|ElastiCache|Upstash|Redis Cloud
Use cases: cache|queue|pub-sub|session|rate-limit|lock
2. Data Structure Selection
| Use Case | Structure | Key Pattern |
| Cache | String/Hash | cache:{entity}:{id} |
| Counter | String (INCR) | count:{entity}:{id} |
| Session | Hash | session:{token} |
| Queue | List (LPUSH/BRPOP) | queue:{name} |
| Unique set | Set | set:{entity}:{scope} |
| Leaderboard | Sorted Set | lb:{game}:{period} |
| Events/log | Stream | stream:{topic} |
| Lock | String (SET NX EX) | lock:{resource} |
IF using wrong structure (String for leaderboard):
wastes memory and complicates operations.
3. Caching Strategies
Cache-aside: app checks Redis, miss->DB->store.
Write-through: write DB+cache simultaneously.
Write-behind: write cache, async flush to DB.
Stampede prevention: lock-based refresh OR
stale-while-revalidate with jitter on TTL.
IF popular key expires and 1000 concurrent requests:
use lock-based cache refresh to prevent stampede.
4. Queue and Pub/Sub
Simple queue: LPUSH + BRPOP (30s timeout)
Reliable queue: BRPOPLPUSH + processing list
Pub/Sub: fire-and-forget (no persistence)
Streams: persistent, consumer groups, ack, replay
IF message must not be lost: use Streams, not Pub/Sub.
IF consumer crashes: Streams with XACK survive it.