That is not an issue that needs to be fixed. You are making too many requests too fast so it is queuing them so you do not exceed the limit. If you are losing data then it is your own fault.
1 Like
It would still be useful as we can write backoff algorithms that are all good citizens. Since we control all access patterns we can be smart as we approach limit.
2 Likes
So for example, if 20 players were to leave the game around the same time and triggers too many requests, would players lose data?
Just checked and this will absolutely kill my daily leaderboard in my experience, every minute the experience makes a request for the top 100 players, this means (with the 100,000 request limit per-queue) I will end up reaching the limit with only 100 servers, which albeit a large number it is not scalable like what Roblox tries to be. This also gives no lee-way for actually saving new data as that will need to make a request.
1 Like
Not if the queue isnât full. Implement your own queue system if you want to protect against it. The message does say that further requests will be dropped if the queue fills.
When the queue get full? Like what is the specific limit requirement for it to start being full and dropping requests?
Hi, itâll be actually 1000 servers to reach the limit. Could you explain why you need to query top 100 players every minute? Is it possible to query on demand instead of polling?
Itâs nice to see the team working out the concerns we have with this as developers.
Oh, seems I canât do basic maths anymore. 
Iâve still always been a person of scalability, if it doesnât scale, I donât like using it. This has seemingly also been in Robloxâs vision too (Datastore limits scale with player count and most MemoryStoreService limits too). Also, this number does not include any additional SetAsync requests I run to update player data too.
My experience uses MemoryStoreService as a daily leaderboard, the values are reset daily (by setting the timeout of the keys to the end of the day) and I need to poll the top 100 players every minute to display the most up to date information on the top users for the current day.
Unfortunately not for my use-case, the leaderboard has to update at a somewhat regular interval (as players leaderboard values will change decently often - once per day, per player when they join, in-which my game previously has hit hundreds of concurrents) and using MessagingService to query on-demand would make it fairly hard to code an efficient system that could make sure servers donât de-sync permanently due to a single failed request or SubscribeAsync failing to connect.
If you would like further details on the implementation of this in my experience, please feel free to message me here on the DevForum. Just that sharing more in-depth information is both a lot of clutter here and likely irrelevant to most people viewing this topic. 
1 Like
Is it possible for the limit quota to switch to Server based instead of Experience?
When I found out about MemoryStoreService I thought of global events systems, for example collecting as many coins as possible together with all the players online in game, but it seems this idea isnât possible with the current limits because the 100,000 requests per minute would be reached quickly, considering you have to loop requests to get the up to date value on all the servers and also request each time the player adds more into the value
since they have to be carefully hardcoded.
The biggest benefit here, you can update global leaderboards so fast!!
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.