Distributed Caching System for Eventual Consistency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed database systems, inconsistencies arise due to lag times in propagating updates across multiple data centers, leading to stale objects being stored in caches, which can result in devices retrieving outdated versions of objects.
Innovation Solution
A system that maintains a list of recently updated object identifiers with time-to-live values to track the propagation status, allowing for the removal of potentially stale objects from caches, ensuring that updated versions are eventually stored across all databases and caches.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If objects are removed from caches after database updates occur, then data consistency is improved, but devices may retrieve stale objects during the propagation lag time
Solution Approach 1:
The system proactively removes objects from caches before the propagation lag time expires, based on detecting that an update has occurred at the database level. This preliminary action prevents stale objects from being served to devices, resolving the contradiction by acting in advance to maintain consistency while accounting for the inevitable propagation delay.
Solution Approach 2:
The system implements a feedback mechanism where cache removal decisions are triggered by database update events. When an update is detected at the database, the system feeds back this information to the cache management component, which then removes the updated object from caches. This feedback loop ensures that cache operations are synchronized with database operations, maintaining data consistency despite propagation delays.
2Speed
If objects remain in caches during propagation lag time, then device access speed is improved, but stale versions of objects are served to devices
Solution Approach 1:
Instead of waiting for propagation to complete before removing objects from cache, the system takes preliminary action by removing objects as soon as database updates are detected. This ensures that even though propagation is still in progress, the cache does not serve stale versions, prioritizing data accuracy over caching speed benefits during the transition period.
Solution Approach 2:
The system converts the harmful effect of propagation lag time into a benefit by using the database update detection mechanism to trigger cache removal. The lag time, which would normally cause stale data to be served, is instead used as a window opportunity to proactively clear caches before stale data could be retrieved, transforming the problem into a solution.
3Difficulty of detecting and measuring
If a list of recently updated object identifiers is maintained, then stale object identification is improved, but system complexity increases
Solution Approach 1:
The system maintains a list of recently updated object identifiers that automatically expires after a predetermined time period without requiring manual intervention. This self-service mechanism handles the complexity of tracking and detecting stale objects automatically, reducing the burden on system operators while improving stale object detection capability.
Solution Approach 2:
The system uses a time-to-live parameter for objects in the cache, which changes based on whether the object has been updated at the database level. When an update is detected, the object's TTL is reset or extended, allowing the system to dynamically adjust cache behavior based on update status. This parameter change mechanism simplifies stale object detection by using temporal information rather than complex validation logic.
Data Source
AI summary
Systems, apparatuses, and methods may provide for an eventually-consistent distributed caching mechanism for database systems. As an example, the system may include a recently updated objects (RUO) manager, which may store object identifiers of recently updated objects and RUO time-to-live values of the object identifiers. As servers read objects from the cache or write objects into the cache, the servers may also check the RUO manager to determine if the object has been updated recently enough to be at risk of being stale or outdated. If so, the servers may invalidate the object stored at the cache as it may be stale, which results in eventual consistency across the distributed database system.