Cache Strategy Considerations and the Role of Redis

Before deploying Redis, it's important to evaluate whether it is truly needed for the application in question.

Redis is typically used in scenarios where an application must handle a very high volume of concurrent users often in the range of hundreds of thousands. In our case, this level of demand does not apply.

If caching is required, we generally have two options:

In-Memory Caching

This is the fastest option but has limitations in clustered environments (e.g., state synchronization, failover).

Dedicated Cache Services

These include Redis, Memcached, and others, which are external systems accessed over the network.

When considering a cache service, the next logical question is: Which one should we use?

All services, whether EMail server, SQL databases, MongoDB, or Redis are accessed over specific protocols (e.g., TDS for SQL Server, TCP for MongoDB or Redis). Performance comparisons often assume Redis is the fastest option, but that assumption can be misleading.

SQL Server: Often provides the fastest response times, especially for indexed lookups on structured data. Believe me or not, the JETDB (MSAccess) is the fastest DB as long the single user is connected. :)

MongoDB: Offers strong performance, particularly in distributed cloud-native environments like Azure Cosmos DB.

Redis: While not inherently the fastest, it excels at horizontal scalability thanks to its built-in partitioning and protocol-level load balancing. This makes Redis suitable for very high-scale scenarios, where clients need to be routed directly to the node holding the relevant data.

So why is Redis frequently used?

Mostly, a lack of Architectural Insight: Many teams adopt Redis without properly researching if it's the best fit.

Scalability Needs: Redis shines in systems that require linear scaling across many users and nodes, which is often not the case in smaller or mid-sized applications.

Conclusion

For systems with fewer than ~1,000 (this needs to be measured for every application!!) concurrent users, it is often more efficient and maintainable to leverage SQL tables directly, avoiding the added complexity and operational overhead of Redis.
I'm not saying, use SQL or MS Access for cache in general. I'm saying, it is smart to understand problem and do required performance measurment before making decisions. Believe me, you will be supried.

Redis is often used as a synonym for caching, just as Docker and Kubernetes are commonly associated with microservices. However, none of these associations are entirely accurate in a generalized context.