You could certainly skip HTTP, have Elixir just reading from Unix domain socket(s), commands in whatever stripped-down format you want to come up with, and the same for writing results back. (Communications over domain sockets is ridiculously fast.)

in this context it’s also good to be aware of something like terraform. The idea would be to put your elixir app before your rails app and per route decide if you handle it with elixir or with ruby. So your elixir app is acting like a reverse proxy in front of your rails app. In this way you can gradually migrate to elixir.

Unsure if there is any authentication or other context you need to handle for the incoming requests from elixir but i’ve done stuff like this by temporarily connecting to the same database as rails (read only) or making internal api routes to get context with from elixir to rails.

Another option is going with a persistent phoenix channel connection from ruby to the elixir app but this would introduce way more complexity (and needs clear interfaces on all sides). Then I would prefer the simplest solution of terraform: handle it with elixir first (via plain HTTP) or else fallback with rails (via plain HTTP).

Just a crazy thought. What if you ran the elixir application in the same OS as the rails app? Then you could make keep-alive requests from Ruby to elixir. It’s not going to be as fast as native Ruby, but it would be fine in a lot of cases.

Known as C Nodes (despotę the name, these do not need to be written in C).