Redis

Common Redis Caching Mistakes (Q&A Format) Q: Our Redis instance is 32GB but our database is only 8GB. Is this normal? A: No, this is a red flag indicating poor cache hygiene. We encountered this exact scenario. Investigation revealed cache entries from: Users inactive for 18+ months Deleted/banned accounts Test accounts from 2023 Orphaned session data Problem root cause: Missing TTL (Time To Live) on cache entries. # ❌ Wrong - lives forever redis.set(cache_key, json.dumps(data)) # ✅ Correct - expires after 1 hour redis.setex(cache_key, 3600, json.dumps(data)) Impact: Set appropriate TTLs → 40% memory reduction immediately. ...

Rate limiting seems simple until it isn’t. We thought we had it figured out - Redis counters, sliding windows, the works. Then a client with a distributed system hit our API and everything fell apart. What we built initially Standard stuff. Token bucket in Redis: def check_rate_limit(api_key: str) -> bool: key = f"rate_limit:{api_key}" current = redis.get(key) if current and int(current) >= 100: # 100 req/min return False pipe = redis.pipeline() pipe.incr(key) pipe.expire(key, 60) pipe.execute() return True Worked great in testing. 100 requests per minute per API key, clean reset every minute. ...

Choosing engine Redis: rich data types, persistence, clustering, scripts; good for queues/rate limits. Memcached: simple KV, pure in-memory, fast; great for stateless caches. Design Namespaced keys, versioned; TTL with jitter; avoid giant values. Pick eviction (LRU/LFU); monitor hit rate and evictions. Stampede control: locks/SETNX, stale-while-revalidate, per-key backoff. Ops Pooling + timeouts; alert on latency, evictions, memory fragmentation. For Redis, persistence config (AOF/RDB) matched to durability needs; replicas for HA. For Memcached, spread slabs; watch for evictions of hot slabs. Checklist Engine chosen per use case; durability/HA decided. TTLs + jitter; stampede protection in place. Metrics for hit/miss/evictions/latency.

Keys & TTLs Namespaced keys: app:domain:entity:id. Set TTLs per data volatility; use jitter to avoid thundering expirations. Version keys on schema changes to prevent stale reads. Stampede protection Use SETNX/lock around rebuild; short lock TTL with fallback. Serve stale-while-revalidate: return cached value, refresh asynchronously. Serialization & size Prefer JSON with bounded fields; compress only large blobs. Avoid massive lists/hashes; paginate or split keys. Operations Monitor hit rate, command latency, memory, evictions. Use connection pooling; set timeouts and retries with backoff. Cluster/replica for HA; read from replicas if consistency allows. Checklist Keys versioned; TTLs with jitter. Stampede controls in place. Metrics for hit/miss/latency/evictions; alerts configured.

Redis is powerful for caching. Here are effective caching strategies. Cache-Aside Pattern async function getUser(id) { // Check cache let user = await redis.get(`user:${id}`); if (user) { return JSON.parse(user); } // Cache miss - fetch from DB user = await db.query('SELECT * FROM users WHERE id = ?', [id]); // Store in cache await redis.setex(`user:${id}`, 3600, JSON.stringify(user)); return user; } Write-Through Pattern async function updateUser(id, data) { // Update database const user = await db.update('users', id, data); // Update cache await redis.setex(`user:${id}`, 3600, JSON.stringify(user)); return user; } Cache Invalidation async function deleteUser(id) { // Delete from database await db.delete('users', id); // Invalidate cache await redis.del(`user:${id}`); } Best Practices Set appropriate TTL Handle cache misses Invalidate properly Monitor cache hit rate Use consistent key patterns Conclusion Implement effective Redis caching strategies! 🔴