In my current architecture, I use RabbitMQ as the message broker. I chose RabbitMQ over other alternatives because it’s already integrated into the system and provides a simple solution for handling WebSocket sessions beyond the in-memory sessions offered by spring websocket library.
A key feature of RabbitMQ is its ability to share user sessions across multiple servers connected to the same RabbitMQ broker. This is crucial for scenarios where users are connected to different servers in a distributed system.
For example, if an admin is connected to Server A via a WebSocket and sends a notification, RabbitMQ ensures that all users connected to the application—regardless of whether their websocket connection is open on Server A or on another server—can receive the notification. This is because RabbitMQ shares user session from and to your application's servers.
To achieve this, the admin publishes the notification to a specific queue (e.g., "notify-queue"). All users subscribed to this queue, no matter which server they are connected to, will receive the message.
If you're considering Kafka as an alternative to RabbitMQ, you should evaluate whether Kafka provides a similar mechanism for distributing messages to WebSocket clients in a multi-server architecture.
Resources: