The idea is to link nodes not to the locations, but to the active groups of players. The node's location therefore will be roughly the geometrical center of the players' group. Do you think it is worth to consider? (the process of a merge/separation of nodes in the closed proximity and/or users' rearrangement between nodes is not depicted here) The source file: https://cdn.discordapp.com/attachments/810122683169636373/898919167577694248/TravellingNodesServerMeshing.puml (Added 10-Nov-21) as per https://robertsspaceindustries.com/comm-link/transmission/18397-Server-Meshing-And-Persistent-Streaming-Q-A Dynamic Server Meshing will be a bit different in that it will constantly re-evaluate how best to distribute the simulation, aiming to find the sweet spot so that no single server is overloaded or underutilized. As players move around the ‘verse, the ideal distribution of processing resources will change. To react to those changes, we’ll need the ability to transfer authority over entities from one server to another, as well as bring new servers online and shut down old ones. This will allow us to move the processing load from a server that is at risk of becoming overloaded to one that is currently underutilized. If none of the existing servers have enough spare capacity to handle an increase in load, we can simply rent more servers from our cloud platform provider. And when some servers don’t have enough load to make them cost-efficient, some of them can transfer their parts of the simulation over to the others and we can shut down the ones we no longer need. ... However, as we start scaling our shards to support higher player counts, the likelihood that every single player within a shard can go to the same physical location and see each other without performance issues will decrease. This is where we will need to start implementing game mechanics that prevent these scenarios from happening too frequently. Also, the "Javelin" problem is acknowledged there.