In this instance, the module I’m writing for my game works similar to ProfileService where when a player is added, their data is reconciled, and then stored in a table where the player is the key, and the value for their key is their data so that scripts can write to their data without actually making new requests each time. Personally, I’m not a huge fan of ProfileService itself, and I like consistency in my code as well.
The questions I have are:
a.) Is this an effective model? Would it be more effective/efficient to just call :UpdateAsync() each time a script needs to write new data rather than storing it how I described above? How would datastore rate limits be handled in this instance?
b.) At what interval should data be saved automatically? Should this be paired with :GetRequestBudgetForRequestType()? If so, what’s an effective way to calculate this interval?
In comparison to caching? No. You should only ever use DataStore requests at important points in a session’s lifetime, which could be any of the following:
Joining the experience
Leaving the experience (including by teleport)
Performing a purchase (you can use MemoryStore to help save requests in case of corruption or to create a processing queue)
Every few minutes (autosave) or by user request (save button with a cooldown)
Any other “important” points where a save should be triggered
Up to you. I’d gun for every 30 seconds as your absolute minimum and the maximum would be dependent on the frequency of data changes; an experience that doesn’t change data much can have a 5-minute maximum autosave interval or greater.
