Question: read-your-writes consistency

Issues
, , ,
7

This came up for us as well. Specifically, because the cache is eventually consistent even when values will be successfully cached, it makes it difficult to write simple unit tests for the code around our ristretto cache. We aren’t able to load a value and then immediately assert if it’s been properly cached.

The performance motivation for asynchronous sets in the cache is important in the production, but when testing, it would be really nice to have a cache with strong consistency.

How would the authors feel about enabling the option for strong consistency? Here are two potential ways to do this:

  1. Add an OnProcessed option to the config (with the same or similar type as OnEvict: func(hashes [2]uint64, value interface{}, cost int64)). This would be similar to the OnEvict option where if it’s not supplied, there are no negative performance implications, but if it is supplied, it enables code to set a value into the cache and then block until it has been processed.

  2. Add an optional parameter to pass in a function into the Set function and then call that function when the item is processed. e.g. something like this.

type CacheValue struct {
   Hashes [2]uint64
   Value interface{}
   Cost int64
   OnProcessed func()
}

cache.SetValue(value)

This could be used instead of cache.Set(...) for use cases where strong consistency is important.