“it depends”.

Running something on a separate node can never be a goal on its own: Why would you want to split your application up into these two things and run that one on a different node?

If you do go ahead and run its on a separate node, the following are possible:

• Connect the nodes directly using Distributed Erlang, and then indeed use :rpc or similar functions (If you restrict what runs on what node, using :rpc is not even necessary, since you can just use GenServer.call directly). Distributed Erlang is however not that well-suited for having the nodes in different data centers across the globe.
• Connect them externally, either by directly communicating (only works when both nodes are available), or using a solution like RabbitMQ (keeps messages when receiver is down; can easily be extended once you add more instances of one of the nodes).
• Connect both nodes to the same datastore, and have this be the ‘single source of truth’. Useful for some applications, but makes your datastore a single point of failure. (And if it is not a distributed datastore, it also might not be that scalable).

And there are other possibilities as well, probably.

Have a care about what events you distribute. It is easy to distribute events that are “too low level” and get unusual cross-service coupling that way. For example, if your ordering system broadcasts “order began”, “item added”, “item removed”, and “order completed” messages, and your inventory system had to respond to all those messages, then any change in the set of events, or their organization, could require changes to both components.

Instead of blindly broadcasting all events, components should have a curated set of semantic events that describe “milestones” for their domain. It’s no different than being careful to define the private or public interface of any other software component - just keep it in mind as you are looking at coupling service through domain events as well.