Caching fundamentalsmedium3-5 years
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?
Cache-aside only ever caches values that exist — a request for a missing product misses the cache, queries the database, finds nothing there either, and caches nothing, so the next request for that same missing id repeats the exact same round trip to the database. This is called cache penetration, and it means a cache provides zero protection against repeated requests for ids that never exist. The fix is negative caching: store a short-lived sentinel value ("looked, not there") the first time a lookup comes back empty, so a repeated request for the same missing id is answered from the cache instead of hitting the database again — the lesson's experiment cut database queries for missing-id requests by two thirds this way.
PreviousA 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?Next A sliding-window rate limiter — allow 10 requests per rolling second per user — is implemented by calling `ZREMRANGEBYSCORE` to trim old entries, then `ZCARD` to count what's left, then conditionally `ZADD`, as three separate Redis commands from application code. Under concurrent requests from the same user, more than 10 get allowed in some windows. What's wrong, and how does wrapping it in a Lua script fix it?
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?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?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?