Redis 7 shipped in April 2022 with some notable improvements: multi-part AOF for persistence, better Lua scripting, and cluster-aware command specs. But I find it more interesting to consider what the release tells us about Redis's place as critical infrastructure and how the in-memory data structure landscape is evolving.
Redis serves many roles in applications - cache, session store, message broker, leaderboard, rate limiter, and distributed lock, often all at once. Its single-threaded event loop with O(1) and O(log n) operations for most data structures makes it predictably fast. The 7.0 release focuses on operational improvements rather than new data structures: better persistence, better scripting, and better cluster tooling.
For example, I've worked on systems that used Redis as a rate limiter, with Lua scripts that would increment counters and block requests when the limit was exceeded. In one such system, we saw a 30% reduction in latency after switching from a database-based rate limiter to Redis, thanks to its in-memory storage and fast script execution. We used Redis Cluster to ensure that the rate limiter was highly available, with automatic failover and horizontal partitioning to handle the high volume of requests.
The IDistributedCache interface in ASP.NET Core provides a consistent API for Redis, SQL Server, and NCache. The recommended caching patterns include cache-aside, where you check the cache and get from the database on a miss, then populate the cache. Another pattern is write-through, where you write to both the cache and database simultaneously. Read-through is another, where the cache transparently fetches from the database on a miss. The cache-aside pattern is the most common in .NET applications using IDistributedCache.
In terms of trade-offs, using Redis as a cache can provide significant performance benefits, but it also requires careful consideration of cache invalidation and expiration. For instance, if you're using Redis to cache database query results, you'll need to ensure that the cache is updated when the underlying data changes. This can be done using techniques like cache tagging or versioning, which allow you to invalidate specific cache entries when the corresponding data changes. We've used the Redis Expire command to set a time-to-live for cache entries, which helps to prevent stale data from accumulating in the cache.
Redis Cluster provides horizontal partitioning and automatic failover. For most applications, a single Redis replica set, with a primary and replicas, provides sufficient throughput, and the replication latency of 1-5ms is acceptable. Cluster is necessary when a single node's memory is insufficient for the data set, or when write throughput exceeds what a single node can handle. Most enterprise applications reach Redis Cluster requirements at hundreds of millions of operations per day.
In practice, setting up and managing a Redis Cluster can be complex, especially in large-scale deployments. We've used tools like RedisInsight and RedisLabs to monitor and manage our Redis Clusters, which provide features like performance monitoring, alerting, and automated failover. These tools can help to simplify the process of managing a Redis Cluster, but they also add additional cost and complexity to the system.
Redis's core data structures are under the BSD licence. However, Redis Stack modules, which include search, JSON, time series, and bloom filters, were moved to non-open-source licences in 2022. This move set a precedent for the HashiCorp BSL change in 2023. In response to Redis Ltd's licence change, the Linux Foundation created a fork of Redis called Valkey in 2024. The open-source core remains available; the question now is where the ecosystem investment will go.