Issue Description
The Limits section of Error Codes and Limits indicates that there are experience-wide limitations to DataStores but it does not specify what those limitations are at all. There is only one example of an experience-wide limit and it uses vague or non-explicit language.
There is a limit on how often an experience (all of its active servers) can call data stores. In particular, requests to a specific key can be throttled if it’s being requested from too many servers at once. To avoid exceeding this limit, use data stores in two contexts:
What limit(s)? The language here implies a singular limitation but DataStores have multiple ways to be used.
What does request mean? Does it refer to all forms of interacting with a key or a specific type of request? This may seem obvious to some developers but not to all.
What constitutes “too many servers”?
Exceed what limit?
The global configurations sample given to “avoid” the experience-wide limits is also weirdly confusing and it’s a terrible example to be using in the context of avoiding limitations as well:
Managing global configurations — If each server is simply reading a value that doesn’t change often, there’s little chance of hitting the threshold.
DataStores have per minute request limits. Querying a global configuration consumes request budget and reduces the budget for other use cases like working with player data. Global configurations is just a standard DataStore use case, how does it avoid experience-wide limitations?
The explanation text of experience-wide limits is that too many servers requesting a key can throttle. Wouldn’t that contradict using DataStores for global configurations unless reading a key’s value does not count as a “request”? See how the language choice is bad?
The Experience Limits tab is so arbitrary and vague that it almost makes no sense to have it but for the sake of documentation and keeping developers informed this section should be more informative on what “experience limits” means and what they are instead of throwing around words with no weight to them.
This documentation would be incredibly helpful for me as I’ve been designing systems that are likely to hit these undocumented limits.
Without knowing exactly what I’m working with, I can only hope that the limit I found out about 5 years ago from Roblox Support (“200 requests per 10 seconds per key”) is still valid, is the only relevant limit, that hitting the limit produces an error rather than using a queue for throttling, and that the limit hasn’t been/won’t be drastically lowered.
IX has expanded a lot more on data limitations with a new section, Request Queues. I don’t know if those were in response to this documentation request and it helps to have newer information about how limits and queues work but this request still hasn’t been fulfilled. In fact, IX axed experience-wide limits off the page and that’s counterinformative.
We know there are server-wide limits to data stores but if there’s also underlying experience-wide limits then developers need to know what those are as well. A majority of experiences on the platform are using data stores and there are many high traffic experiences with them as well. Either these “experience-wide limits” don’t exist or they need to be documented, please.
Some of the front-page games have 10k servers or more. Testing it now, a single server can read 4MB of data (from a single key) in about a second. Just to confirm, are you saying all 10k servers could read from that same key at the same time and all receive the up-to-date value within a few seconds?
If so, this seems like a huge upgrade to data stores!