Design of a Unified WebSocket Messaging Service for Backend Systems

Background : The existing backend systems suffer from tight coupling with frontend web components and rely on polling for asynchronous results, leading to high latency and maintenance overhead. Introducing a unified WebSocket (WS) communication service aims to replace polling, support real‑time push, improve response rates, and accommodate future WS‑based features.

Goals :

Standardize WS project structure and coding conventions.

Separate business logic to accelerate integration.

Replace unreasonable polling with push notifications.

Transform synchronous calls into asynchronous WS pushes to improve overall system responsiveness.

Use MQ instead of Redis pub/sub for microservice communication.

Core Design : The architecture abstracts WS as an internal communication service, supporting fan‑out message publishing, topic‑based subscription, and detailed business flow diagrams (client registration, server push, client receipt).

Reliability Guarantees :

Message loss can occur at three points: producer‑to‑RabbitMQ transmission, RabbitMQ persistence failure, and consumer processing failure. Two producer‑side reliability mechanisms are recommended:

Transactional mode: enable RabbitMQ transactions and roll back on failure using channel.txRollback() .

Publisher confirm mode: enable confirm mechanism; on success the broker returns an ACK, otherwise a NACK triggers a retry.

Confirm mode is asynchronous and offers higher throughput, making it the preferred choice for most producers.

On the broker side, persistence (durable messages) ensures data survives server restarts.

Consumer reliability is achieved by disabling auto‑ack and using manual acknowledgments ( consumer ack ) after business logic completes, allowing RabbitMQ to re‑queue unacknowledged messages.

Message Classification :

Client → Server: client initiates a message, e.g., QR code refresh requests.

Server → Client: server pushes results, e.g., payment callback notifications.

Client → Client: peer‑to‑peer messages, e.g., user‑initiated updates to an H5 page.

WebSocket API Design :

1. Request a WS connection token via a GET request to domain/xxx/websocket/token , which returns JSON containing the WS URL.

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

2. Connect to the WS using the returned URL, e.g., wss://dws.test.com:8086/socket/{token} .

Unified Message Body (JSON format):

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

Unified Call Method : The WS API is encapsulated into an aggregated client library, providing a single entry point for all business modules to send and receive messages without dealing with low‑level WS configuration.

Conclusion : The document records a DDD‑inspired design for a unified WebSocket messaging service, reducing code coupling and enabling "plug‑and‑play" real‑time communication for various backend business scenarios, while abstracting away underlying WS setup and logic.