When using Aerospike as a simple LRU cache, as many do, I think the policy of Aerospike to “only removes data that has a TTL set and chooses the soonest to expire records to evict first” (as noted here: http://www.aerospike.com/docs/operations/configure/namespace/retention) is a sensible default given the current setup/capabilities. However it leaves something to be desired for people with LRU caching needs.
An ideal scenario would be to optionally enable read tracking within aerospike whereby aerospike would track times read and last read time. This data is critical for LRU (least recently used) since the data with the most cache hits is the most useful to remain cached - even if it has a shorter TTL - I would rather the longer TTL stuff gets evicted before something that gets 5000x more cache hits but has a shorter TTL to force a certain freshness of data. This is a common pattern in LRU caches and does not have a great solution in Aerospike.
But since the ideal scenario results in performance hits and complexity due to more writes to track read usage… another option might be to allow app developers to set an optional eviction priority. This way we can let aerospike know to kill this stuff off before others. For example, lets say priority was a 1 byte int - Aerospike could start the same eviction logic as far as the shortest TTL, but it would start first with the lowest priority and then work its way up to higher priority eviction tiers once it cleared others out.