Valkeyaside with client-side caching TTL defined separately from valkey-side TTL

[davidlin-tv2]

I feel kind of 50/50 on if it's a bug or not, but not leaning so far into it to make me raise as an issue. My expectations when using valkeyaside is that the ClientTTL option inside of ClientOptions would impact the client side caching TTL. For example, if I do a .Get(24*time.Hour) while having set ClientTTL to time.Minute, I would expect the entry to live inside of valkey for 24 hours, but only in my service for a minute.

I can see in the code at https://github.com/valkey-io/valkey-go/blob/main/valkeyaside/aside.go#L153 that the ttl is put into the DoCache and I wonder if it might be a typo? If not, I think it would be a nice feature to have.

For example in the use case I'm looking at now, I'd like to protect my relatively static DB from bursty traffic that can happen after an initial cache-warming connection. With valkeyaside as I understand it now, if you want the data to live in valkey for a long time, you have to accept a high memory footprint in your app.

Think it might be an easy enough addition as a ClientOption (or if the current ClientTTL is meant to handle that case already), but probably not worth the breaking change of being able to have it get .Get() call.

[rueian]

Hi @davidlin-tv2,

ClientTTL is totally a different thing. It is for a client health check marker for other clients to know if the client is still alive.

I can see in the code at https://github.com/valkey-io/valkey-go/blob/main/valkeyaside/aside.go#L153 that the ttl is put into the DoCache and I wonder if it might be a typo? If not, I think it would be a nice feature to have.

It is not a typo. The TTL is both the client and server TTL. DoCache implements redis server-assisted client-side caching. The idea of that is Redis will notify the client to invalidate the client-side cache once the key has been changed on the server side. This way, you dramatically reduce the chance of getting stale data from the client cache. But in other words, the lifetime of a client cache will only be smaller than or equal to the server's.

With valkeyaside as I understand it now, if you want the data to live in valkey for a long time, you have to accept a high memory footprint in your app.

Currently, you can control the client-side memory footprint by adjusting the CacheSizeEachConn option. Excessive client cache will be evicted by LRU. But please note that CacheSizeEachConn is an approximation. The actual memory footprint could be higher.