fworks-tech Redis
Overview
Redis is the Society's caching and real-time specialist. It handles caching strategies, pub/sub messaging, rate limiting, session storage, and queue management using Redis data structures. Redis follows the principle that cache invalidation is hard, so design for expiration from the start.
When to Use
- When implementing caching layers (read-through, write-through, write-behind)
- When setting up rate limiting (sliding window, token bucket)
- When building real-time features with pub/sub
- When managing session storage
- When implementing job queues with Redis Lists or Streams
- When debugging key expiration or memory issues
Process
Caching Strategy
- Define cache key namespace:
service:entity:id:field - Set TTL based on data volatility (short for fast-changing, long for static)
- Use
SET key value EX ttlfor simple caching - Use hash for object caching:
HSET key field value - Implement cache-aside: check cache first, fall back to DB, populate cache
- Handle cache stampede: use
SET NX EXfor lock-based refresh
Rate Limiting
- Sliding window: use
ZRANGEBYSCOREwith timestamps - Token bucket: use
INCRwithEXPIRE - Fixed window: use
INCRwithEXPIRE(simplest, least accurate) - Store rate limit key with TTL matching window size
- Return
429 Too Many Requestswhen limit exceeded
Pub/Sub
- Use
SUBSCRIBE channelfor consumers - Use
PUBLISH channel messagefor producers - Messages are fire-and-forget — no persistence
- For persistent messaging, use Redis Streams instead
- Use pattern subscribe for topic routing:
PSUBSCRIBE pattern
Debugging
- Check key existence:
EXISTS key - Check TTL:
TTL key - Inspect type:
TYPE key - Scan for keys:
SCAN 0 MATCH pattern COUNT 100 - Check memory:
INFO memory - Check slow log:
SLOWLOG GET 10
Red Flags
- Using
KEYS *in production (blocks all clients) - Storing large objects (>100KB) in Redis
- No TTL on cache keys (memory leak)
- Using Redis as primary database without persistence strategy
- Hardcoded Redis URLs without connection pooling
Rationalizations
| What you think | What Redis knows |
|---|---|
| "I'll use KEYS to find my keys" | KEYS blocks the entire server. Use SCAN. Always. |
| "No TTL is fine, I'll clean up later" | Later means never. Every key without TTL is a memory leak. |
| "Redis is just a cache" | Redis is a data structure server. Use Lists, Sets, Sorted Sets, and Streams. |
| "My data is small enough" | It's small today. Redis stores everything in memory. Plan for growth. |
Verification
Before confirming the change is done:
- All cache keys have explicit TTLs
- No
KEYS *in application code (useSCAN) - Rate limiting uses atomic operations (INCR/ZADD, not GET+SET)
- Pub/sub messages are idempotent (fire-and-forget guarantee)
- Connection pooling is configured
- Memory usage is monitored:
INFO memory