Read and write frequently updated data
Hi, we're working on a game where we would have non-player-related data (both read and written) updated quite frequently (every 5 seconds or so).
Which data structure in the Playfab API would be best suited for this?
We know that Title Data is out of the question because of its sharded and cached condition. We've also thought of treating the world and its data as a player, and access/modify its data via cloudscripting but we're unsure if its an optimal solution.
We'd be really thankful for any advice or directions on the subject.
Thank you!
Best Answer
Definitely not title or player data. But what to use depends on what triggers the updates and how it's accessed. If this is data that will be updated from a few sources, and which will be accessed by a few sources, an Entity Object or File would likely be best.
Since you said it'll only be updated every five seconds or so, presumably it's only being written from a small number of sources. If it's being written from many sources, I would expect it to be a much higher frequency, but let me know if I'm misinterpreting your description.
So then, the question becomes how often is it read, and by what? If this is data that will be read by every player in the game (so, potentially millions of requests per minute), I'd have to direct you to use something like Redis, since you either have to have a sharded/cached resource (like CDN or Title Data) or else an in-memory data cache, in order to service that level of requests.
It's also worth highlighting that you'll be spinning one of the meters on every write and read if you use our data systems, so high frequency writes and reads are generally something you'll want to avoid. If you can describe the high-level design in more detail, we might be able to provide more specific suggestions.
Hi Brendan !
Thanks for your answer. I'll try to describe what we do 
: in the past, we made several small "solo" games in gamejams and sometimes we use a "fake" DB (storing KVP data in some web API) to store what we call "world data" (data not related to a specific player but to the main gameplay experience). It's not multiplayer but players still have an impact on each other.
For instance (https://savvy-community.itch.io/) in "PUMPKARE", everytime a player wins or loses a minigame, the shared-score of all player is improved or reduced and a pumpkin grows or diminishes (so there's only a score in our DB, only one key/one value). In "COLOR DUTY", a game where the player is stuck in a maze full of rooms, he can tag a door as a trap or a good door and each time he does so, other players see the statistic associated and decide to trust or not the community (we store the first player who cleared a floor of rooms and data related to each/door of each rooms ... it's not a lot). In these previous games we didn't have a lot of players (very low CCU so not really a problem of concurrent access) and the gameplay was related to a finite data count that was either growing slowly or not all (+)
(+) (we're really sorry for the gigantic smiley, we absolutely didn't expect it)
But in our last game "PASSAGES", we hit the limit of our "fake DB" in term of storage (500KB of KVP data) because we had to store a lot of data for each players (each time the player fail an attempt, his trajectory is saved in the DB, and other players can see some trajectories of all players in a level). And we had more players than usual... So we decided to have a look at playfab.
After some research, we know that some of our gameplay could be translated as playfab "player data" (data related to each player like trajectory per level in PASSAGES), but we were wondering how to read/write "shared data" related to the world/shared gameplay like a common score in "PUMPKARE" or like info on the doors in "COLOR DUTY".
Thanks
Yes, in the web game examples above, there isn't a database being used for storage - the data is simply that of the current session, with all players contributing to one or more variables the server is tracking.
What you're describing is a data store that a) is written to based on player actions, b) is read by all players, and c) is frequently updated. If it's data that is only relevant to players in a session together, keeping it in the "state" info you have in a server hosting the session would be the way to go. If you want it to be a shared data store across all players of the entire game, you would need to use an in-memory data store like Redis.
