Updated with these rates.
If a write call errors, does it still activate the write cooldown?
Sorry for the late reply â in my testing only successful requests seem to affect the write cooldown for a given key. This is reflected in the MockDataStoreService implementation.
Is there any sort of budget when contention occurs with an UpdateAsync call involving many servers for the same key?
The rest is why Iâm asking the question
If youâre wondering, Iâm creating a seasonal leaderboard using MemoryStoreService and Iâm worried about hitting some back-end queue(? Could just be an array of requests that is randomly chosen from) designed for UpdateAsync contentions. It shouldnât ever hit any of the other limits (The keys are sharded and cached to reduce the amount of MemoryStoreService calls), but this one is worrisome since it is mostly unavoidable if the other limits were not reached.
The most worrisome part is a season ending because the code fires an UpdateAsync in every reserved server currently running a game in order to get the most up-to-date scores at a seasonâs end. The lobby servers wait 30 seconds for all of the updates to complete, then they all use UpdateAsync() to check if the season has already been updated and update the leaderboards if no other server has performed the season change yet.
The only problem is the reserved servers all fire the UpdateAsync at the same time and could potentially fill up some contention queue on the back-end. I suppose I could give the reserved servers some random time to update in those 30 seconds to spread out the requests, but if there is a hard-limit then I very well may have dropped requests and data loss; especially if the limit is very low.
Your question is solely related to MemoryStoreService and not about DataStoreService, right? This post is only about datastores and does not consider memory stores, they are completely different services with different under-the-hood implementations and different properties w.r.t. persistence and consistency.
Generally speaking, MemoryStoreService seems to be implemented as a layer around a caching cluster (most likely Redis under the hood is my guess) and so it does not suffer from a âwrite cooldownâ like datastores as much. However no system scales infinitely with the number of requests against a single key, so you should try to avoid creating âhot keyâ situations in your datastores/memorystore usage design as much as possible.
I do apologize for being outside the scope of this resource, but this post was the closest information I could find regarding my question.
Thank you for the quick reply as well as answering an out-of-place question.
It should be okay because the reserved servers carry a cached leaderboard last place that is used before an UpdateAsync is ever called. Only the amount of players with a current leaderboard-ranking score will ever call UpdateAsync from the reserved servers. It should be a maximum of 200 calls with an expectation of only a few calls, but Iâll spread them out over some time just to be extra safe.