How to properly organize websocket proxying from third-party services?

Question

Software design

There is a need to receive signals from several exchanges and send notifications to users on their signals.
The site also needs to show this data.

I want to make the following system:

1. A websocket proxy service that will connect to all the necessary websockets and send messages to the appropriate channels via rabbitmq
2. Consumers, who, accordingly, will subscribe to these channels and do what is needed. Including sending these signals to the site. Those. a service for sending notifications, a service for updating data in the database, a service for broadcasting these signals to websocket subscribers on the site, etc.

Is everything OK in this scheme and what are its weak points?

Answer 1

If I understand correctly, we are talking about cryptocurrency exchanges (since exchanges from the stock market do not have websockets), each exchange has its own websocket connection format (for example, pure php ratchet is enough for many, and for some you need Thruway WAMP). Each exchange has its own troubles, limits on the number of connection subscriptions, jambs with a stuck channel (there is no data connection), etc.
I strongly recommend physically separating the collection of raw data and their processing into processes.

Answer 2

Your scheme is quite viable. The rabbitmq queue consumers can consume the same queue in multiple threads, i.e. the system scales horizontally. The main issue will be with sharding and client sockets to direct events from your consumers to your clients. Depending on the expected load, it is worth introducing another transport layer into your scheme - transport to the client