I’m working on a bank system, where each player has their own cash and bank, and there is a bank ran by higher ranks that tax the players and store the money… This works fine and all, however. Recently I’ve discovered an issue. I’m using DataStores to save the money (The Bank amounts is defined by a value placed ingame and is saved to datastore every 2 minutes)
If there’s multiple servers, is there a way I can sustain this so that the bank amounts are universally the same?
For example, if the bank is deposited into in one server, it’ll update in all.
Deposits will be quite frequent, due to it taxing players during their everyday use of the currency, which is why I do not want to exceed the limit for DSS.
May anyone throw me an explanation on how to do this?
From what I gathered, DataStore2 may the best use case for you. DataStores save data across all servers and if there are any errors with limits/general failures, it can take care of that for you.
Hi. I’d personally LOVE to use DataStore2, but as shown above, it is a global value, and DS2 can not only not save to offline players (needs a player instance), it can’t save to any specific key… it requires a player instance to work. Tried this out, if I could use it, I definitely would.
Edit: Meaning, DataStore2 only works when I have a player which I’m saving Data in-game. It doesn’t work for saving Data in general to a specific key like normal RBLX datastores. I’d have to fork the script, and change it, etc. And I don’t know how to do that.
Oh woops, you would have to write a custom script for it then. If your bank account saves every 2 minutes, surely data in other servers will not be written? What would maybe be more ideal for your use case is to save it every time data is written, while this may be more resource hungry, it will ensure that data does not go missing, example: If the bank has $100. A player in 1 server may take the $100, but since it hasn’t updated yet, Player 2 in a different server still see’s the $100.
This is what I want… But it’ll destroy my ratelimits. I have jobs that pay per minute, it is constantly taxing, and changing values etc therefore it’d exceed the limit of DataStores and go into an annoying queue.
Yes. The money from a global bank pays them, and also taxes them when they give others money, alongside takes money when a player purchases an in-game item with money.
Ah right, one suggestion could be to save on an external source? This would maybe end up being more reliable compared to Roblox DataStores. Since hosting externally, you would not have to worry about request overloading since the host would not have limits. That is if you decide to use cloud hosting. There may be a more efficient way to do this but that is the only idea I have at the moment.
You may use any cloud hosting provider, I am not too familiar with those due to hosting my own Ubuntu servers. This is however just an idea and I haven’t tried using it to store Roblox data. I believe there are some posts on this forum in relation to external databases if that is any use for you? I’ll add you on Discord to see if I can assist further.
Account balances can be updated at a regular interval, a good candidate for this would be the new memory stores. Not everything needs to be communicated in real time. When a user spends or earns money, they are taxed and the taxed money doesn’t have to appear in the “higher ups” accounts instantly. For things that need to be instantaneous (such as withdrawals) you should use messaging service. You should design this system in such a way that it would eliminate issues such as the double spend problem.
If you go this route be sure to look into the memory store’s limits regarding data expiry to ensure you don’t lose any account balance information. You might have to implement data stores alongside this for more persistent storage.
It would be very resourceful to send out every request for editing the amount, depending on the game size, multiple players could be sending out data every second. Would that particularly matter? Sorry for the delayed reply.