Debouncing Cache Updates

Multiple update calls to cache needs to be rejected / debounced — only one needs to go through.

Scenario

If cache needs to be updated after a threshold — in the period where the cache TTL threshold has reached , multiple updates to the cache needs to be debounced

Solution — Mutex locking

Maintain a hash set in redis which stores key value pairs where key is the redis key of the data that is being accessed and value is true or false based on whether the lock has already been acquired.

For example let ‘xyz’ be the redis key of the data being read. The corresponding mutex hash set (named ‘mutexHashSet’) in redis would be

{ ‘xyz’:false ‘anotherKey’:false }

Flow for scaling updates to independent cache clusters.

For every set redis call on the key ‘xyz’

• get the corresponding key from mutexHashSet
• if the value is true — if lock has been acquired lready — return
• if not continue
• set the key ‘xyz’ in the mutexHashSet to true — acquire lock
• Perform operations on the data
• get the expiry time
• if the threshold has reached
• update cache — return
• set the key ‘xyz’ in the mutexHashSet to false — release lock

Conclusion

The above solution makes sure that multiple updates to the cache during the time the cache is being updated is rejected.