Yes we’re expecting the record to no longer exist. Really 1 second precision is an incredibly blunt object for the use case we’re considering so even if it existed no longer than exactly 1 second from a put operation until a subsequent get that’s still too long.
We get heavy hotspots of many thousands of requests per second, and the data cannot really be over 1 second stale. The solution is very short lived caches (under 1 second). Redis works fantastic for this at the moment with 800ms caches and from set - get if we’re over it at all, the record is gone.
If we test against Aerospike and Redis with 1 second TTL on the data, we don’t see the data in Redis after 1.1 second while Aerospike it’s a bit more inconsistent but it seems >1 and <2 always.
The clocks are synced but interestingly, even if the clock is skewed on Redis we still get accurate expiration.
It’s ok if this kind of sub 1s TTL precision isn’t planned, it’s clear with the minimum value of 1 it’s not really currently intended or incredibly short lived memory caches. We’d love to move those caches to Aerospike if/when TTL precision increases though. In the meantime longer lived caches (10s+) will definitely be moved.