Hello, I have come with a curious question about the Redis caching for the proxy instances. First of all I would like to get an insight into what is actually cached in it. My investigation shows that the only things that is really put into it, is the features JSON with one entry per SDK key. That leads me to the conclusion that the cached amount of data will really be minimal and measured in megabytes. For some reason I expect that, with remote evaluation on, the cache would also cache the evaluted-per-context result but that does not seem to be the case (I don’t know why I assume that, it says it nowhere 😇). That will influence the instance size I will be using for caching so a confirmation here would be nice. Furthermore I am wondering about the actual usefulness of adding Redis at all. If the amount of data is really that low we might us well just use the in-memory caching in the proxy instances. Browsing trough the code I have found two things the Redis cache enables: • All proxy instances will hit Redis first and continue to do so for

CACHE_STALE_TTL

seconds. So we will take load from the API instances. Assuming I leave the state TTL at one minute: even with hundreds of proxy instances running the API would only see that many requests per minute and I feel it should be able to handle that just fine?! • The proxies are kept in sync. I browsed through the

RedisCache

implementation and what I see is the following: ◦ If one of the instances notices the features JSON change for any of the SDK keys it will notify the other instances via Pub/Sub. ▪︎ Those instances will then immediately refresh their in-memory cache layer. That is nice, but I noticed that the in-memory cache layer, when using Redis, is only having a stale TTL of 1 second. So the maximum time the Redis notification would remove from “different proxy instance having different states” is that one second. ▪︎ They will also notify any clients connected via server send events so they can update immediately. I’m not sure we will be using SSE and I also see a potential downside: If you notify all clients simultaneously they will also all go a update their state at the same time, creating a bit of a thundering herd problem (unless there is an artificial jitter in the SEE implementation - I have not checked in detail) Did I miss anything where Redis is used or did I make any mistakes in my analysis? Because if not I think I might not setup Redis for out deployment. One less piece of infrastructure to manage and monitor