Redis vs HTTP for communications between services

We have a monolithic Rails API that was also serving our Websockets. Recently, we outgrew ActionCable and we decided to move our Websockets to Elixir's Phoenix.

In this model clients still interact with the Rails application for HTTP requests, but Phoenix handles all the Websocket traffic. Rails communicates to Phoenix what data to send and on what channel then Phoenix acts essentially as a passthrough for what Rails sends it.

I had initially set this up using Redis PubSub for communication from Rails to Phoenix. It works well at its current scale, but I'm starting to think that it may have been an inferior choice. Here is my list of pros and cons:

Redis

Pros:

• Ordered messages (not important in our case)
• Acts as a proper queuing mechanism
• Wicked fast and dead simple publishing from Rails

Cons:

• No competitive consumers - I would have to manually implement balancing if I had multiple Phoenix consumers (a real possibility)
• Concurrency is more difficult to implement well (which really acts against Elixir's strengths)

HTTP

Pros:

• Concurrency comes for free
• Load balancing comes for free - a request will only be fulfilled by a single Phoenix consumer
• Slightly more simple to implement

Cons:

• Unordered messages (not important for us)
• Much slower to send a message from Rails
• Would have to manually implement retry and timeouts on the HTTP requests from Rails
• If a message is lost (due to server restarts or similar), it's gone for good

---

Even after weighing it out, I still find it hard to claim one as being the clear choice. Are there patterns for Redis or HTTP communication between services that alleviate some of my problems? If not, which of these two would be preferred, considering the cons?

Is there another simple alternative that I'm overlooking? I don't want to involve something like Rabbit MQ if it can be avoided.