How are parties discovered in distributed Nakama instances?

As I can understand from the source code, parties are stored as a Map in the memory on the Nakama server instance at the time of party creation and are deleted from the Map once the party ceases to exist. (ref)

I want to understand how this functions in a scenario where we have multiple Nakama instances in a distributed system. Since parties live on a single system’s memory (assumption) when a user queries the request needs to be sent to the same Nakama instance to access the party details.

Are users’ requests routed to the same Nakama instance that created the party when they search for it? If yes, is it on the basis of the session id / source IP of the user or party id? Or is it random (very unlikely)?

Actually, we are planning to use an in-memory storage to store party IDs and some related metadata. if the requests are sent to instances based on user ids or other player request information, we can create an entry in all the systems for the specific users and hence maintain in-memory storage without going for a distributed caching solution.


  1. Versions: Nakama {3.5}, {Windows, Mac, Linux binary or Docker}, {client library (SDK) and version}
  2. Server Framework Runtime language (If relevant) {Go, TS/JS, Lua}
{code or log snippet}

:tv: Media:

Hi @thealphadollar, how parties are handled in distributed computing scenarios is not public information at this time. Nakama Enterprise, which is bundled with Heroic Cloud, is designed so that you don’t need to implement your own caching layer on top of it. We recommend using Heroic Cloud or signing a support contract with us if you have a specialized use case.

1 Like