CLIENT TRACKING landed in Redis 6 four years ago. StackExchange.Redis still doesn't support it.

In 2020, Redis 6 introduced a feature called CLIENT TRACKING which allowed the server to push invalidations whenever a key a client had read changed anywhere. However, StackExchange.Redis, a popular .NET client for Redis, never implemented this feature. This left developers with an option to fork the project or find an alternative solution.

RedisNearCache is a package that sits alongside StackExchange.Redis. It enables developers to continue using their existing multiplexer, while simultaneously handling client tracking and invalidation. To use RedisNearCache, developers simply need to add a second connection and manage it through RedisNearCache. The API for RedisNearCache is identical to StackExchange.Redis, making the transition seamless.

There are two main modes for RedisNearCache: REDIRECT-based tracking for self-hosted, ElastiCache node-based, or Azure Cache for Redis; and Broadcast mode for Redis Enterprise-based services like Azure Managed Redis, Redis Cloud, or Redis Software. The Broadcast mode requires a separate RESP3 connection per master and subscription to invalidations for a key prefix.

A benchmark test compared RedisNearCache with other caching solutions like IMemoryCache, HybridCache, and FusionCache. The test showed that RedisNearCache provided accurate tracking and significantly reduced stale reads compared to TTL-based options. While TTL-based solutions may have higher raw throughput, they served stale data over 80% of the time in the tested workload. RedisNearCache, on the other hand, offered a more accurate and up-to-date caching experience, albeit with slightly lower raw throughput.