Redis caching

The most common Redis use case: sit between your app and a slower store (database, API) to absorb hot reads. The default pattern is cache-aside (read-through): app checks Redis first, on miss fetches from DB and writes to Redis with a TTL. Three things to get right or everything breaks: invalidation — "there are only two hard things in CS: cache invalidation and naming things" is an old joke that's still true; when source data changes, the cache must know, either via explicit delete on write or short TTLs as a safety net. Stampede — TTL expires on a hot key, 1000 requests simultaneously miss, all hammer the DB — solutions are lock-then-refresh patterns or probabilistic early refresh. Consistency — the cache is always slightly stale; if a workflow can't tolerate that (checkout totals, balance reads right before withdrawal), either bypass the cache or use write-through. Cache sessions, query results, rendered pages, API responses — anything read often and updated rarely.