Redis and the art of caching
Cache-aside, sessions, rate limits and lightweight queues — where Redis earns its keep, and the two rules that keep a cache from becoming an unreliable database.
Our reporting queries were melting the database every morning, and the hardware upgrade quote made my eyes water. What fixed it instead was an in-memory store, a handful of cache keys, and a lesson I keep re-learning: the fastest query is the one you don't run.
Where Redis earns its keep
- Cache-aside for expensive reads. Dashboards, report summaries, anything a thousand parents view but one cron job computes. Compute once, serve from memory, expire on a TTL.
- Sessions — moving them out of the database dropped a shocking amount of write load we'd stopped even noticing.
- Rate limiting and counters — atomic increments make abuse control almost embarrassingly simple.
- Lightweight queues — before you need a real broker, a Redis list gets background jobs off the request thread.
The two hard things
The old joke holds — cache invalidation really is one of the two hard problems. Our working rules: every key gets a TTL, no exceptions, because "stale for at most five minutes" is a promise you can reason about and "invalidated correctly by seven code paths" is not. And the cache must be allowed to disappear — if flushing Redis takes your product down, you didn't build a cache, you built an unreliable database.
A cache is a lie you tell your users about how fast you are. Keep the lie small and honest.
The reporting cluster survived result day on the old hardware, the upgrade quote went in the bin, and I gained a permanent first question for every performance complaint: "what are we computing twice?"