I’ve only used :rpc (or software that used rpc, erpc looks like a newer version) and I’ve never really hit limits on this. The situation was:

1. Everything was in same dc(no wan)
2. Everything was trusted.
3. Less than 15 nodes connected (other network topologies exist that can connect more, but it was unnecessary as boxes wese beefy).

I don’t think there’s any reason not to use it? The alteratives aren’t that great either. Spending cpu serializing/deserializing json over http? After seeing 25% of the cpu going to parsing, deciding to go to a binary format like messagepack? As long as everything is trusted, single datacenter, and no reason to talk to non-BEAM languages, why not use the standard protocol? For instance, I never had any issues with riak clusters and I can’t think of any application that would be more chatty.

Then on modern hardware, I don’t think it will be very easy to hit the limits. Anyway, for further information:

Personally, I would be more concerned about security and the introduction of other languages than the scale in most situations.

Looking into this more, erpc is significantly different than rpc. The issue that is commonly raised is that the original rpc implementation relied on a single GenServer process named rex to handle rpc calls. This causes performance degradation under high call volumes due to mailbox flooding. The charts in the DE-Bench PDF above indicate that using spawn instead of rpc is not subject to the same limits, as it spins up a new process per-call.

erpc basically builds the alternative approach into the Erlang kernel, using spawn_request to make that actual request to the remote node as mentioned in the Kernel 7.0 release notes and found in the Erlang erpc implementation. rex is entirely absent from the :erpc implementation, and rpc itself now relies on erpc for many operations, likely for this reason.

The theoretical limitations of erpc may be the port blocking described in the gen_rpc library README. For the purposes of using erpc to make intra-cluster API calls with reasonably sized response payloads, this is probably not an issue.

To be fair I’m not a big fan of doing rpc calls without a predefined contract, that can be enforced on both ends, it is just too easy to break the contract by accident.

IMO a monolith that has good separation of code will be times more easier to manage than those 2 separate services trying to communicate via rpc.