Redis

We were spending $12,000/month on Redis before I realized we were doing it completely wrong. Not “slightly inefficient” wrong. Full-on “why is our cache bigger than our database” wrong. Here’s what I learned after three months of firefighting and optimization. The problem nobody warned us about Our Redis instance hit 32GB of memory. Our actual PostgreSQL database? 8GB. Something was very, very wrong. Started digging through our caching logic. Found this gem: ...

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! 🔴