Difficulties making a 'Remove Friend' system

At the moment, I am in the process of creating my own ‘friends’ system for a multi-place game. This feature essentially allows players to add other users as ‘friends’, who they can then follow around the server, follow into other servers, and see when their friend was last online:

I have completed every feature for this system except from the remove friend feature:

In simple, all you do is remove the ‘friend value’ found in each player’s data. This proves easy to do if both players are in the same server, however once the players are in different servers, this becomes very difficult.

I’ve had a look into three methods so far:

1) Creating a whole new datastore, with every single player’s ID, and an associated list with 'friends to remove’
For example:

local removal_list = {82347291 = {}, 82347292 = {82347293, 82347294} }

Then, when that player joins a server, the server will scan through their associated list, and remove every player in that last. In the example, the player with the ID ‘82347293’, would then remove the players with IDs 82347293 and 82347294 from their friends.

To save this list and retrieve the data, I used :UpdateAsync

Down side: As soon as multiple servers start doing this, :UpdateAsync requests start to throttle and pile up, and it becomes impossible to save/retrieve the values.

2) As soon as a player removes a friend who is in a different server/offline, instantly update the friend’s data to remove their ‘friends value’.

Down side: All someone has to do is add lots of players as friends, then ‘unfriend’ all of them in one-go.
Result: data-store goes boom and I exceed the maximum number of datastore requests

3) Don’t bother trying to remove the player from the universe right away; just wait until both players are in a server together, and then remove the ‘friend values’.

This actually works, but it means the friends system is ‘cheating’, as a player is only removing the ‘friend value’ from their side, and not from their removed-friend’s side too.

As a last resort, I would have no choice but to chose this method, but I really don’t want to go down that path.

In simple, I’m looking for an effective way to remove friends, even when one is not in the same server, without exceeding my datastore limits. I’ve been racking my brains all day for another method, but can’t come up with an effective one. Any ideas?

Thank you if you read all of that; any solutions/ideas are greatly appreciated.
You can try out the friends system so far here: Guest World (Read Description!) - Roblox

1 Like

Only use GetAsync when they join, and SetAsync when they leave. While they are in game, just use a module to control their friends list.

My bad, that was a typo: I meant :UpdateAsync, not :GetAsync

I’d personally go with the second option, but add a rate limit of sorts to the remote and requests. Example:

  • Player A friends Player B
  • Client sends request to Server
  • Server checks if Client had exceeded 5 datastore requests
  • Allow the request if under, ignore if over.
  • Reset limit every 60 seconds

this should prevent abuse while allowing for instant updating of friends data for those intending to use it correctly


rip was already replying before you removed
Yeah, use UpdateAsync as GetAsync caches and can lead to using outdated data, Update will ensure you’re updating what the DS has and not cache.

If you create data for Players in any fashion (which you do), throw in an additional variable to that data such as “requestsMade” and keep it locally on the server. Just simply check to see if it’s not over, and do your logic. Come time to save data, filter out the requestsMade variable if you’re picky about not letting it be persistenting data (which I would be, you should always start fresh on a new session so they have their full 5 requests)


Yep, that’s just what I’ve done. Thank you for your help!

I’ve set the request cap to 7, as that gives a 3-request-leeway in case of auto-save and the player leaving save all happening within a short-period of time.