Designing a Scalable WebSocket Messaging Service with Reliable RabbitMQ Integration

Background

Our company previously had many backend services tightly coupled with frontend web interactions. Introducing WebSocket (ws) for instant communication required significant effort, so we abstracted WebSocket into an internal communication service to address various business needs such as polling replacement, push notifications, asynchronous call refactoring, and future real‑time requirements.

Business used polling to obtain asynchronous results (payment callbacks, order processing).

Some features required instant push (QR code refresh, charging port status).

Improve response speed by converting synchronous calls to asynchronous and pushing results via WebSocket.

Prepare for future business that needs real‑time communication.

Goals

Standardize ws communication project structure and coding style.

Separate business logic to improve integration efficiency.

Replace unreasonable polling with push mechanisms.

Support conversion of synchronous calls to asynchronous, delivering results through ws to improve overall system responsiveness.

Use MQ instead of Redis pub/sub and micro‑service calls.

Core Design

Project Structure

Business Process

3.1 Application Relationship Diagram

Message Push (Fanout)

Message Receiving (Topic)

3.2 Business Sequence Diagram

From top to bottom:

WebSocket client registers and connects.

Server receives and processes push messages.

Server pushes messages to the client.

Ensuring Reliable Message Transmission

During design we must prevent message loss. For RabbitMQ three loss scenarios are considered:

Producer fails to deliver the message to the server.

Server crashes before persisting the message.

Consumer crashes after receiving the message but before processing it.

✔ Ensure producer reliability (two methods)

Method 1: Enable transaction mechanism; if sending fails, channel.txRollback() is called and the message is retried.

Method 2: Enable publisher confirms; the broker returns an ack on success or a nack on failure, allowing the producer to retry.

Comparison: Transactions are synchronous and block the thread, while confirms are asynchronous and provide higher throughput, so confirms are generally preferred.

✔ How the MQ server guarantees no loss

Persist messages to disk so that after a broker restart the stored messages can be recovered.

✔ Ensure consumer reliability

Disable automatic ack and use manual acknowledgments ( consumer ack). The consumer acknowledges only after business logic succeeds; otherwise the message is re‑queued for another consumer.

Message Classification

5.1 Client → Server

Client actively pushes messages to the server, triggering server‑side business processes. Example: QR code scan refresh requests.

5.2 Server → Client

Server initiates events and pushes results to a client. Example: Payment completion callbacks.

5.3 Client → Client

One client pushes messages to another client. Example: C‑end user request results displayed on an H5 page.

WebSocket API Design

6.1 Request WebSocket connection token

Method: GET

Endpoint:

domain/xxx/websocket/token

{
  "result": 0,
  "description": "无",
  "data": "wss://dws.test.com:8086/socket/asrwqgvsd"
}

6.2 Connect using the returned URL

Connection scheme: wss

URL format:

wss://dws.test.com:8086/socket/{token}

Unified Message Body

{
  "sendType": "",
  "messageType": "消息类型",
  "businessType": "",
  "fromUniqueId": "发送端唯一id",
  "toUniqueId": "接收端唯一id",
  "fromClientType": "发送端类型",
  "toClientType": "接收端类型",
  "timestamp": 0,
  "content": "业务数据",
  "tags": ["标签集"],
  "businesses": ["业务集"]
}

Unified Call Method

8.1 WebSocket API aggregation wrapper

8.2 Business unified invocation

Conclusion

This article documents the overall design of an abstracted, unified WebSocket messaging solution. By applying DDD principles, the implementation reduces code coupling and enables “plug‑and‑play” real‑time communication for various business scenarios without worrying about low‑level WebSocket configuration.