vibeeval Redis Patterns
Advanced Redis usage beyond simple key-value caching.
Data Structure Selection
Use Case → Structure → Why
Session store → Hash → Partial field updates without full deserialize
Rate limiter → Sorted Set → ZRANGEBYSCORE for sliding window
Job queue → List + Stream → BRPOPLPUSH for reliable queue
Leaderboard → Sorted Set → ZREVRANGE with scores
Unique visitors → HyperLogLog → O(1) cardinality, 0.81% error
Feature flags → Hash → HGET per flag, HGETALL for bulk
Presence (who's online) → Set → SADD/SREM, SMEMBERS
Geolocation → Geo → GEOSEARCH within radius
Distributed Lock (Redlock-lite)
import Redis from 'ioredis'
const redis = new Redis(process.env.REDIS_URL!)
async function acquireLock(
key: string,
ttlMs: number = 10_000
): Promise<string | null> {
const token = crypto.randomUUID()
const acquired = await redis.set(
`lock:${key}`, token,
'PX', ttlMs,
'NX' // Only set if not exists
)
return acquired === 'OK' ? token : null
}
async function releaseLock(key: string, token: string): Promise<boolean> {
// Lua script: only delete if token matches (atomic check-and-delete)
const script = `
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
`
const result = await redis.eval(script, 1, `lock:${key}`, token)
return result === 1
}
// Usage
async function processExclusively(resourceId: string): Promise<void> {
const token = await acquireLock(resourceId, 5000)
if (!token) throw new Error('Could not acquire lock')
try {
await doWork(resourceId)
} finally {
await releaseLock(resourceId, token)
}
}
Sliding Window Rate Limiter
async function isRateLimited(
userId: string,
maxRequests: number,
windowMs: number
): Promise<boolean> {
const key = `ratelimit:${userId}`
const now = Date.now()
const windowStart = now - windowMs
const pipeline = redis.pipeline()
pipeline.zremrangebyscore(key, 0, windowStart) // Remove expired entries
pipeline.zadd(key, now.toString(), `${now}:${crypto.randomUUID()}`)
pipeline.zcard(key) // Count entries in window
pipeline.pexpire(key, windowMs) // Auto-cleanup
const results = await pipeline.exec()
const count = results![2][1] as number
return count > maxRequests
}
Lua Scripting for Atomicity
// Problem: check-then-act is not atomic with separate commands
// Solution: Lua script executes atomically on Redis server
// Atomic counter with ceiling
const incrementWithCeiling = `
local current = tonumber(redis.call("GET", KEYS[1]) or "0")
local ceiling = tonumber(ARGV[1])
if current >= ceiling then
return -1
end
return redis.call("INCR", KEYS[1])
`
async function tryIncrement(key: string, max: number): Promise<number> {
const result = await redis.eval(incrementWithCeiling, 1, key, max.toString())
return result as number // -1 means ceiling reached
}
// Atomic dequeue with conditional processing
const dequeueIfReady = `
local item = redis.call("LPOP", KEYS[1])
if item == nil then return nil end
local data = cjson.decode(item)
if data.scheduledAt and tonumber(data.scheduledAt) > tonumber(ARGV[1]) then
redis.call("LPUSH", KEYS[1], item) -- Put back, not ready yet
return nil
end
redis.call("SADD", KEYS[2], item) -- Move to processing set
return item
`
Pipeline for Bulk Operations
// Without pipeline: N round trips
// With pipeline: 1 round trip for N commands
async function bulkGetUsers(userIds: string[]): Promise<Map<string, User>> {
const pipeline = redis.pipeline()
for (const id of userIds) {
pipeline.hgetall(`user:${id}`)
}
const results = await pipeline.exec()
const userMap = new Map<string, User>()
for (let i = 0; i < userIds.length; i++) {
const [err, data] = results![i]
if (!err && data && Object.keys(data as object).length > 0) {
userMap.set(userIds[i], data as User)
}
}
return userMap
}
Pub/Sub with Redis Streams
// Streams > Pub/Sub: persistence, consumer groups, acknowledgment
// Producer
async function publishEvent(stream: string, event: Record<string, string>): Promise<string> {
// MAXLEN ~ 10000: approximate trimming for performance
return redis.xadd(stream, 'MAXLEN', '~', '10000', '*', ...Object.entries(event).flat())
}
// Consumer group setup
await redis.xgroup('CREATE', 'events', 'worker-group', '0', 'MKSTREAM')
// Consumer
async function consumeEvents(
stream: string,
group: string,
consumer: string
): Promise<void> {
while (true) {
const entries = await redis.xreadgroup(
'GROUP', group, consumer,
'COUNT', '10',
'BLOCK', '5000', // Block up to 5s for new messages
'STREAMS', stream, '>'
)
if (!entries) continue
for (const [, messages] of entries) {
for (const [id, fields] of messages) {
try {
await processEvent(Object.fromEntries(
fields.reduce((acc: [string, string][], v, i, arr) =>
i % 2 === 0 ? [...acc, [v, arr[i + 1]]] : acc, []
)
))
await redis.xack(stream, group, id)
} catch (err) {
console.error(`Failed to process ${id}:`, err)
// Message stays pending, will be re-delivered
}
}
}
}
}
Checklist
- Use appropriate data structure for each use case (not everything is a string)
- Pipeline bulk operations (avoid N round trips)
- Lua scripts for atomic multi-step operations
- Set TTL on every key (avoid memory leaks)
- Use SCAN instead of KEYS in production (KEYS blocks)
- Configure maxmemory-policy (allkeys-lru for cache, noeviction for queue)
- Monitor slow log:
SLOWLOG GET 10 - Streams over Pub/Sub when message persistence needed
Anti-Patterns
- Using KEYS * in production (blocks entire Redis, use SCAN)
- Storing large values (>1MB) in a single key (fragment or compress)
- No TTL on keys: silent memory leak until OOM
- Check-then-set without Lua: race condition between GET and SET
- Using Redis as primary database without persistence config (RDB/AOF)
- Single Redis instance for both cache and queue (eviction kills queue items)