A very quick rundown of your options:

• Registry is local only
• gproc has a global mode but the consensus is that it is unreliable. so consider it local only.
• you can use pg (part of OTP) if you need a distributed process group (duplicate keys)
• you can use global (part of OTP) if you need a distributed process registry (unique keys)
• you can also use syn - you seem to already be aware of its pros/cons
• you can also use Phoenix.Tracker, which is part of the phoenix_pubsub project, as a distributed process group (duplicate keys)

EDIT: Updated in 2023 to mention pg instead of pg2 in Erlang/OTP.

Sorry for the late reply, I’m not active on these forums.

FYI and anyone interested, contrary to what stated here above Syn does not require all nodes to be connected before it can be initialized. The only requirement is that a node joining a cluster first connects to it before calling syn:init/0. This of course does not mean that all nodes need to be connected before syn can be initialized. Example code is in the README.

So yes, it is absolutely possible to add nodes to a running cluster and everything will work fine.

you can also use syn - you seem to already be aware of its cons

@josevalim would you mind expanding? I didn’t understand what cons you are referring to and I’d be happy to take yours and any feedback that could make it better.

Best,
r.

The simple (and boring) answer is that distributed registry is really, really hard to get right. The OTP team is already working on improving what’s available in Erlang itself, so there’s no need to duplicate efforts.

Ultimately, gproc is the answer. It has already solved the problem (and you will end up running into problems it has already solved). Take the functions you already created and use them as wrappers around the gproc calls.

Are you just using Registry like a pubsub system?

If you’re using it for a PubSub then you are probably running a :duplicate registry, in which case there are better ways in handling Broadcasting across nodes than using Registry.dispatch.

If you want to build it yourself and still use most of your Registry implementation then what you need to do is have a Broadcaster at each node that is part of a :pg2 group or something. Then this Broadcaster is actually in charge of dispatching messages.

When it receives a local message it broadcasts the message to the other Broadcaster processes in the :pg2 group then runs Registry.dispatch/3 locally. When it receives a message from another node it just runs Registry.dispatch/3 locally.

That’s basically what phoenix_pubsub does. If you need something more than just PubSub that Registry provided then I would still recommend a per node Orchestrator process of some kind.

Once again though, this is for :duplicate registries. If you are using a :unique registry then @michalmuskala comment about registration being hard becomes the plain fact of the matter.