This blog post explores the innovative use of Redis 6 client tracking to improve client-side caching solutions, addressing common challenges in data consistency and network traffic. It discusses the architecture of a typical web application, the problems of stale data in client-side caches, and how Redis 6's new features can optimize caching strategies for better performance and reliability.
Welcome to a deep dive into leveraging Redis 6 tracking for effective client-side caching. My name is Ben Malik, a principal engineer at Paylocity, an online payroll and human capital management provider. Our journey with Redis began four to five years ago, initially using it as an ASP.NET session state store. Over time, we expanded its use for caching, leading to a hybrid solution that combines Redis with client-side caches.
In a typical web application architecture, multiple web servers operate behind a load balancer, all driven by a SQL backend. To enhance performance, we implement client-side caches on these web servers. This setup is beneficial for displaying frequently accessed data that does not change often, as it reduces the load on the SQL database.
However, a significant challenge arises when a user updates their information, such as changing their username. In this scenario, the web server processing the update will modify the SQL backend and update its client-side cache. Unfortunately, other web servers may still hold stale values in their caches, leading to inconsistencies when they serve requests.
One common approach to address this issue is to broadcast updates across all web servers. However, this method often results in excessive network traffic and can introduce complex bugs due to the asynchronous nature of updates. For instance, if two web servers update the same value simultaneously, there is no guarantee that the last update will be the one that all servers receive last, leading to confusion and stale data.
Another solution is to eliminate client-side caches altogether and rely solely on Redis. While this approach ensures consistency, it introduces latency due to the TCP round-trip required for each Redis access, which can be detrimental when multiple values need to be retrieved quickly.
To overcome these challenges, we developed a hybrid solution that utilizes both Redis and client-side caches. When an update occurs, we write the new value to Redis and send an invalidation message to the other web servers, instructing them to fetch the updated value from Redis the next time it is requested. This method maintains Redis as the source of truth while minimizing network traffic.
At Paylocity, we further optimized this by broadcasting a hash of the key instead of the key itself, significantly reducing the size of synchronization messages and network traffic.
Redis 6 introduced a new feature called client tracking, which enhances our caching strategy. This feature allows Redis to keep track of which clients have requested specific keys. When a key is updated, Redis can send invalidation messages only to clients that have previously requested that key, thus reducing unnecessary network traffic.
Redis client tracking operates in two modes: default and broadcast. In default mode, Redis tracks all clients that have requested a key, sending invalidation messages only to those clients when the key is updated. This method is efficient but requires more memory on the Redis server to maintain the tracking data.
In contrast, broadcast mode does not track which clients requested which keys. Instead, it sends invalidation messages to all clients that have opted into client tracking. While this mode reduces memory usage, it can increase network traffic since messages are sent to clients that may not be interested in the updates.
Redis also provides opt-in and opt-out options for client tracking. In opt-in mode, clients must explicitly request to receive invalidation messages for specific keys. Conversely, in opt-out mode, clients automatically receive invalidation messages unless they specify otherwise. The choice between these modes depends on the application's caching behavior and the importance of network synchronization versus memory usage.
To implement an effective caching strategy using Redis client tracking, follow these steps:
At Paylocity, we plan to utilize broadcast mode for our caching strategy, as it aligns well with our data access patterns. We also aim to adopt Redis 3, which supports push notifications, allowing us to streamline our connections and reduce the number of TCP connections needed for pub/sub messages.
Redis 6 client tracking offers a powerful solution for managing client-side caching effectively. By leveraging its features, we can ensure data consistency, reduce network traffic, and enhance the performance of our applications. As we continue to explore and implement these strategies, we look forward to further optimizing our caching solutions for better user experiences.
Thank you for your attention, and I hope you enjoy the rest of the presentations at RedisConf 2020!
