Redis Patterns

# Redis Patterns

## Data structures
- **String**: SET/GET, INCR for counters, with TTL: `SET k v EX 60`
- **Hash**: object storage `HSET user:1 name A email a@b.c`
- **List**: queue `LPUSH/RPOP`, capped log `LPUSH ... LTRIM 0 999`
- **Set**: unique members, intersections (mutual friends)
- **Sorted Set**: leaderboards `ZADD score member`, range `ZRANGE`
- **Stream**: event log with consumer groups `XADD/XREAD`

## Cache-aside
```pseudo
v = redis.get(k)
if v is None:
  v = db.fetch(k)
  redis.set(k, v, ex=300)
return v
```
Invalidate on write. Use jittered TTL to avoid thundering herd.

## Rate limit (token bucket via Lua)
Simpler: fixed window
```
key = "rl:" + user_id + ":" + minute
count = redis.incr(key)
if count == 1: redis.expire(key, 60)
if count > LIMIT: reject
```

## Distributed lock (Redlock-lite single-node)
```
SET lock:resource <random> NX EX 30
# do work
# release: Lua compare-and-delete to avoid releasing someone else's lock
```

## Pub/Sub
- `SUBSCRIBE chan` / `PUBLISH chan msg`
- For durable delivery prefer Streams + consumer groups.

## Pipelining vs transactions
- Pipeline: batch commands, fewer round-trips (no atomicity).
- MULTI/EXEC: atomic, but other clients can still INTERLEAVE READS only between TX.
- Lua scripts: atomic + server-side logic.

## Gotchas
- Don't use `KEYS *` in prod -> use `SCAN`.
- Watch eviction policy (`maxmemory-policy`).
- Beware of big keys / hot keys.