When to Use Redis: Caching Patterns for Web Applications

Redis gets added to a lot of projects as a reflex rather than a decision. Here's how we actually think about when it earns its place.

Session storage is the clearest case. If you're running multiple application servers (or serverless functions), you need session state to live somewhere outside the process. Redis is fast, supports TTL natively, and handles the concurrent access patterns of session data well. This is almost always worth it once you're past a single server.

Query result caching is where it gets more nuanced. The pattern is simple: hash the query parameters, check Redis before hitting the database, store the result with a TTL if it's a miss. The hard part is cache invalidation. We only cache queries where the acceptable staleness is clear and the invalidation logic is simple. "Show me the current stock level" should not be cached. "Show me the list of product categories" can be cached for an hour.

Rate limiting is one of our favourite Redis use cases. The token bucket and sliding window algorithms map naturally onto Redis data structures. You get atomic operations via Lua scripts, which means your rate limit logic is correct even under high concurrency. We use this on every API we build.

Pub/sub for real-time features. Redis pub/sub is not a message queue — messages are not persisted, and if a subscriber is offline it misses them. But for use cases like "notify all connected clients that stock has changed", it's exactly the right tool. Simple, fast, and easy to reason about.

Job queues. Libraries like BullMQ use Redis as a backing store for background job queues. This works well for tasks like sending emails, generating reports, or processing uploads — anything that shouldn't block the request/response cycle.

What Redis is not good for: primary data storage, complex queries, or anything requiring ACID transactions across multiple keys. We've seen projects use Redis as their main database to avoid PostgreSQL complexity. It always ends badly.