Caching
Topic, then cluster, then study. Recently added is the short list at the top.
Recently added
Show more- 7.Cache Invalidation — TTL vs Event-Driven vs Versioned KeysInvalidation is how you stop serving lies. TTL is the safety net, event-driven DEL tracks writes, and versions stop a slow reader from writing an old snapshot back after your DEL. Combine them and design for the invalidation path failing.
- 8.Distributed Caching Consistency — Local vs Shared Cache & Near-CacheA near-cache (L1 in each pod) on top of a shared L2 (Redis) removes the network hop for hot keys, but every write must now reach every pod. Invalidate L2, fan out a versioned message to every L1, keep L1 TTL short, and flush L1 when a subscriber reconnects.
- 3.Cache TTL Design & JitterTTL is a staleness bound. Identical TTLs create expiry cliffs. Add jitter; use soft TTL / XFetch on hot keys; size TTL from business tolerance, not habit.
- 5.Negative CachingCache the fact that a key does not exist with a distinct sentinel and a short TTL. Invalidate on create. Miss storms on absent keys are as dangerous as hot hits.
- 6.Redis Eviction Policies & Memory Managementmaxmemory plus a policy. Caches usually allkeys-lru or allkeys-lfu. volatile-* protects keys without TTL. noeviction makes writes fail. Pick string/hash/list/set/zset/stream from the access pattern; RDB vs AOF vs none from durability. Eviction is not capacity planning.
- 4.Single-Flight Locking for Cache FillsCoalesce concurrent misses with SET NX PX. Lock TTL vs load p99. Token + Lua unlock. Waiters poll the data key. Combine with in-process singleflight.
Caching
Latency wins, stampede control, and invalidation that does not lie.
Redis cache
8 studies- 1.Redis Cache-Aside, Invalidation & Stampede PreventionCache-aside + delete-on-write; TTL jitter; single-flight SET NX PX + Lua unlock; XFetch; negative caching.
- 2.Write-Through vs Write-Behind CachingCache-aside invalidates after DB commit. Write-through warms cache on the write path. Write-behind acks from cache/queue and flushes later — faster writes, durability risk.
- 3.Cache TTL Design & JitterTTL is a staleness bound. Identical TTLs create expiry cliffs. Add jitter; use soft TTL / XFetch on hot keys; size TTL from business tolerance, not habit.
- 4.Single-Flight Locking for Cache FillsCoalesce concurrent misses with SET NX PX. Lock TTL vs load p99. Token + Lua unlock. Waiters poll the data key. Combine with in-process singleflight.
- 5.Negative CachingCache the fact that a key does not exist with a distinct sentinel and a short TTL. Invalidate on create. Miss storms on absent keys are as dangerous as hot hits.
- 6.Redis Eviction Policies & Memory Managementmaxmemory plus a policy. Caches usually allkeys-lru or allkeys-lfu. volatile-* protects keys without TTL. noeviction makes writes fail. Pick string/hash/list/set/zset/stream from the access pattern; RDB vs AOF vs none from durability. Eviction is not capacity planning.
- 7.Cache Invalidation — TTL vs Event-Driven vs Versioned KeysInvalidation is how you stop serving lies. TTL is the safety net, event-driven DEL tracks writes, and versions stop a slow reader from writing an old snapshot back after your DEL. Combine them and design for the invalidation path failing.
- 8.Distributed Caching Consistency — Local vs Shared Cache & Near-CacheA near-cache (L1 in each pod) on top of a shared L2 (Redis) removes the network hop for hot keys, but every write must now reach every pod. Invalidate L2, fan out a versioned message to every L1, keep L1 TTL short, and flush L1 when a subscriber reconnects.