I think that for 1) to have only-once guarantee you need some kind of distributed transaction algorithm because connections might fail and you don't know the state of the request in the remote node: Is the remote node dead? is it alive and just disconnected because a network failure? how far into the request processing did it go before the failure?
You should check mnesia , it's deeply integrated with Erlang.
If you relax the requirements for 1) (for instance if the requests are idempotent. you only care for at-least-once or the failures are not common), it may suffice with monitoring the remote gen_server and just replaying the request if the connection to the remote server is lost for whatever reason.
For 2 we use haproxy or nginx webserver in a least-conn fashion in front of the nodes, although I believe that you mean 'inside' Erlang. In that case I'd do the following to have a local ETS with the load info:

1. Have a MODULE sidekick that broadcasts the local MODULE 's mailbox size (or other metric) periodically to other sidekicks in the cluster.
2. If the sidekick receives this broadcast, it writes the origin node and size into an ETS or just saves them internally and stores the least-busy for the time being in an ETS
3. If the sidekick notices that a remote node disconnects, it updates the ETS
   Regarding OTP23's pg , don't discard it so easily. By the doc Process Groups implement strong eventual consistency. you may have overloaded servers leave the process group temporarily and they will eventually stop receiving requests. You can have several servers by node with a low trigger to leave the group for a more uniform distribution.