I'm designing a system where pairs of clients need to exchange messages proxied by a backend service. My initial plan was to use websockets and have the clients connect to a single websocket server, but this doesn't scale obviously. One popular design for scaling websocket servers is to use multiple websocket servers, and broker messages on the back end with some sort of pub/sub message broker (redis, or similar).
Given that my requirement is only for pairs of clients to communicate (no chat-like behavior), and I only need at-most-once delivery, is there any advantage to using a message broker over just having the hosts communicate directly? Or phrased differently, is there any reason not to just have the servers communicate directly?
i.e., in this context, are there any advantages to this:
To clarify the question a bit more, my concern is that a message broker adds an extra bit of infrastructure without the expected gains in scalability in this scenario. In most uses where a message broker is recommended, there is 1-to-many communication (chat apps, multiplayer gaming etc), where a message broker could add pub/sub capabilities, or message buffering/durability. In this case, I have only pairs of clients, and fire-and-forget messaging is adequate. It would also be trivial to have the servers hosting each side of the conversations exchange messages directly. So I'm wondering if there are other advantages to message brokers that I am missing in this context.
For reference, I'm anticipating several thousand concurrent sessions each consisting of a pair of clients.