Caching fundamentalseasy0-2 years
A team adds a Redis cache in front of a product lookup and is surprised the win is only partly about speed — what does a cache actually buy beyond raw latency, and why should every cached entry get a TTL even when the application also deletes the entry on every write?
Speed is real — a Redis GET measured at about 75 microseconds against a roughly 2.6 millisecond database query, around 35 times faster — but the other half of the win is that every cache hit is a database query that never happens at all, which matters most when the database could technically answer fast enough but not thousands of times a second. A TTL matters even with careful write-side invalidation because it's the upper bound on how long any bug, missed evict call, or race condition can serve wrong data — an application can always forget to invalidate on some code path, but it can't forget the TTL, because Redis enforces it regardless of what the application does or doesn't do correctly.
PreviousA service increments a page-view counter in Redis by doing `GET counter`, adding one in application code, then `SET counter <newValue>`. Under load from several instances, the final count is consistently lower than the number of requests. What's happening, and what's the one-line fix?Next A service stores one Redis hash per user session, and a new feature proposes merging in a second, related hash of many more fields under the same key rather than keeping two separate hash keys, on the grounds that "one key is simpler." What actually changes about the memory cost as the merged hash grows, and why isn't merging automatically the cheaper choice?
A Redis cache configured with `maxmemory-policy allkeys-lru` holds a tenth of the working set under realistic skewed traffic. A teammate suggests switching to `allkeys-lfu` to improve the hit ratio. Would that help, and what's actually being tuned when the eviction policy changes?A scraper walking through sequential product ids, many of which don't exist, is sending every one of those requests straight through the cache to the database, even though the service already uses cache-aside. Why doesn't cache-aside help here, and what closes the gap?Under write latency pressure, a team proposes switching a Redis-backed cache from write-through to write-behind: acknowledge the write immediately, buffer it, and flush to the database on a schedule. What exactly is being traded away, and is it a bug to fix or a tradeoff to make deliberately?