Optimistic Concurrency Lock Support in `IDistributedCache`
- Dominant language
- C#
- Stars
- 38.4k
- Forks
- 10.9k
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 281
Description
In large-scale distributed systems with many instances, updating values in a distributed cache can be challenging due to the risk of concurrent writes. Multiple instances may attempt to modify the same cache entry simultaneously, leading to overwrites and potential data loss.
### Describe the solution you'd like
To address this challenge, I'd like to request the addition of optimistic concurrency lock support to the `IDistributedCache` interface, especially for the Redis implementation (ideally for all). This feature will allow instances to detect and resolve concurrent write conflicts when updating cache entries.
#### Proposed Solution
Implement an optimistic concurrency lock mechanism in `IDistributedCache` that uses versioning or token-based checks to detect concurrent writes. If a write conflict is detected, the instance can either retry the update after re-reading the latest value or handle the conflict in a predefined manner.
The solution should also include a flexible conflict resolution strategy to handle scenarios where multiple instances try to update the same cache entry simultaneously.
### Additional context
#### Real-Life Scenario
Let's consider an e-commerce platform that uses `IDistributedCache` with Redis to cache product inventory levels. The platform has 100+ instances, and each instance can update inventory levels based on user purchases.
Imagine the following sequence of events:
1. Instance A reads the inventory level for Product X from the cache, which is currently set to 10.
2. Instance B reads the inventory level for Product X from the cache, which is also 10.
3. Instance A updates the inventory level to 9 after processing a purchase of Product X.
4. Instance B updates the inventory level to 9 after processing another purchase of Product X.
In the absence of an optimistic concurrency lock mechanism, the final inventory level in the cache would be 9, even though two purchases were made. This can lead to stock discrepancies and ultimately impact the customer experience.
Contributor guide
Assessment
This issue has not been assessed yet.