DatabaseRedisPerformanceCachingSystem DesignBackend
Production Redis: Caching Strategies, Invalidation & Cache Stampede Prevention
The Illusion of Simple Caching
"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton.
In introductory tutorials, caching is portrayed as a trivial two-line problem:
python# Naive caching data = redis.get(key) if not data: data = db.query(...) redis.set(key, data, ex=3600) return data
In high-concurrency production systems serving 20,000 requests per second, this naive approach can trigger a catastrophic outage known as the Cache Stampede (Dogpiling).
When a heavily queried cache key expires, thousands of concurrent incoming requests simultaneously detect a cache miss and blast the underlying database with identical heavy queries—instantly overwhelming database connection pools and bringing down your infrastructure.
In this guide, we break down battle-tested caching architectures, invalidation strategies, and robust stampede prevention mechanisms.
1. The Three Fundamental Caching Patterns
1. Cache-Aside (Lazy Loading):
App ──► Read Cache ──► Miss ──► Read DB ──► Populate Cache
2. Write-Through:
App ──► Write Cache ──► Cache writes directly to DB ──► Success
3. Write-Behind (Write-Back):
App ──► Write Cache (Immediate Ack) ──► Asynchronous Queue ──► Batch DB Write
Which Pattern Should You Choose?
- Cache-Aside: The universal standard for read-heavy web applications. Resilient to cache crashes, but requires proactive invalidation on updates.
- Write-Through: Ensures cache and database consistency at the expense of higher write latency.
- Write-Behind (Write-Back): Phenomenal for high-frequency write operations (like real-time video game telemetry or IoT sensor logs), but carries risk of data loss if the cache node crashes before flushing to disk.
2. Preventing the Cache Stampede (Dogpiling)
When a hot key (like the homepage product catalog or trending news item) expires, how do you prevent 5,000 workers from hitting the database at the exact same millisecond?
Solution A: Distributed Mutual Exclusion (Mutex) Lock
Only the first request that encounters a cache miss is allowed to acquire a distributed lock in Redis and query the database. All other requests wait briefly and re-read the freshly repopulated cache:
python# stampede_mutex.py import time import json import redis r = redis.Redis(host='localhost', port=6379, db=0) def get_product_catalog_safe(product_id: str) -> dict: cache_key = f"product:{product_id}" lock_key = f"lock:{cache_key}" # 1. Attempt reading from Redis cached_val = r.get(cache_key) if cached_val: return json.loads(cached_val) # 2. Cache Miss: Attempt to acquire distributed lock (10s expiry) acquire_lock = r.set(lock_key, "locked", nx=True, ex=10) if acquire_lock: try: # Sole winner: query database db_data = fetch_product_from_postgres(product_id) # Repopulate cache (1 hour TTL) r.set(cache_key, json.dumps(db_data), ex=3600) return db_data finally: # Release lock r.delete(lock_key) else: # Other 4,999 requests wait 50ms and retry from cache time.sleep(0.05) return get_product_catalog_safe(product_id)
Solution B: Probabilistic Early Expiration (XFetch Algorithm)
Instead of waiting for a key to strictly expire at second zero, the application calculates a probability of refreshing the key before it expires, scaled by how frequently it is requested:
$$\Delta \cdot \beta \cdot \ln(\text{random}()) > \text{remaining_ttl}$$
python# xfetch_cache.py import math import random import time def should_refresh_early(expiry_time: float, computation_time: float, beta: float = 1.0) -> bool: """ XFetch algorithm for optimal early cache refreshing. Args: expiry_time: Epoch timestamp when cache expires computation_time: Delta seconds required to compute value from DB beta: Aggressiveness factor (> 0.0) """ remaining_ttl = expiry_time - time.time() if remaining_ttl <= 0: return True # Probabilistic early trigger return (computation_time * beta * math.log(random.random())) > remaining_ttl
With XFetch, high-traffic keys are seamlessly recalculated in the background before they ever expire, guaranteeing zero cache misses for active users.
3. Cache Invalidation Best Practices
A. TTL Jitter (Avoid Synchronous Expiry)
If you cache 100,000 products with a static
ex=3600, all 100,000 keys expire together exactly one hour later. Always add random jitter:python# 1 hour ± random 5 minutes jitter ttl_with_jitter = 3600 + random.randint(-300, 300) redis.set(key, value, ex=ttl_with_jitter)
B. Event-Driven Invalidation via Kafka / CDC
Instead of relying on timers, trigger invalidations immediately when data mutates in the primary database:
- User updates their profile in PostgreSQL.
- PostgreSQL emits a Change Data Capture (CDC) event via Debezium or an application event via Kafka.
- Invalidation workers receive the event and issue
redis.delete(f"user:{user_id}").
By engineering for stampede prevention and distributed invalidation, your caching layer delivers rock-solid, sub-millisecond latencies under the heaviest production traffic spikes.