The Hardest Problem in Caching

Stale data causes bugs that are hard to reproduce and hard to debug. Know your strategies before you cache anything in production.

Cache-Aside (Lazy Loading)

Application code checks the cache first. On miss, fetch from DB and write to cache. On update, invalidate the cache entry:

# On write: delete the stale key
await db.update('UPDATE users SET name=$1 WHERE id=$2', [name, id]);
await redis.del(`user:${id}`);

Next read will miss and repopulate. Simple but risks a window of stale data between write and invalidation.

Write-Through

Write to cache and database simultaneously. Reads always hit cache. No stale reads but higher write latency. Good for read-heavy workloads where write speed is acceptable.

Write-Behind (Write-Back)

Write to cache immediately and flush to database asynchronously. Lowest write latency but risk of data loss if cache fails before flush. Use only when you can tolerate some loss such as analytics counters.

Cache Stampede

When a hot key expires, all concurrent requests miss simultaneously and hammer the database. Prevent with a mutex lock or probabilistic early expiration — recompute the cache slightly before TTL expires based on a probability that increases as expiry approaches.