How Go‑Powered IM Architecture Boosted E‑commerce Messaging Performance

Technical Background and Challenges

Instant messaging (IM) is critical for e‑commerce, especially travel platforms, where users need continuous communication before, during, and after purchase. The original IM relied on PHP‑based long‑polling and later OpenResty+Lua, which caused high server load, complex maintenance, and limited scalability.

Goal of the Go Refactor

The redesign aims to decouple business logic from the IM service, provide flexible access via HTTP and WebSocket, and build a scalable distributed architecture.

Language Choice

Go was selected for its high performance in I/O‑bound scenarios, near C/C++ speed, and rapid development experience, especially for developers with C++ background.

Two‑Layer Distributed IM Architecture

The architecture consists of four layers:

Presentation Layer : Offers both HTTP and WebSocket entry points.

Business Layer : Handles message decoding, customer assignment, and sensitive‑word filtering. HTTP requests deliver JSON to the business server; WebSocket bypasses the dispatcher.

Service Layer : Comprises Dispatcher and Worker nodes. The Dispatcher locates the appropriate Worker via RPC and forwards messages, which the Worker pushes to clients through WebSocket.

Data Layer : Redis cluster stores user identity, connection info, and client platform keys.

Service Flow

Step 1 : Client establishes a WebSocket long‑connection; connection info is recorded in Redis.

Step 2 : User sends a message via HTTP; the business server decodes JSON, assigns a customer service representative if needed, and stores the message asynchronously.

Step 3 : Business server forwards the message to the Dispatcher.

Step 4 : Dispatcher uses RPC to route the message to the target Worker based on Redis connection data.

Step 5 : Worker pushes the message to the client via WebSocket and expects an ACK; missing ACK triggers retransmission.

System Integrity Design

Reliability : Implements timeout retransmission (default 18 s, three retries) and historical message pull after reconnection.

Multi‑Device Sync : Uses Redis Hash to store connection keys, enabling synchronization across PC, web, and mobile clients.

Availability : Chooses RPCX for inter‑service RPC due to performance and governance; employs ETCD for service registration and discovery, ensuring automatic failover.

Scalability : Both Dispatcher and Worker can be horizontally scaled to handle increased load.

Security : Introduces blacklist mechanisms to limit abusive UID or IP connections.

Performance Optimizations and Pitfalls

Switched from Go's standard JSON to json‑iterator for faster serialization (see benchmark chart).

Removed frequent time.After usage in heartbeat goroutine to reduce memory churn.

Replaced unsafe map access with sync.Map to avoid concurrent map panics.

Handled goroutine exit coordination between read and write loops in Gorilla/WebSocket implementation.

Optimized logging with Uber's Zap library for low‑overhead structured logs.

Performance Testing

Under a simulated load of 1 million concurrent connections (50 Docker containers, each with 20 k connections), the server used ~30 GB memory. Latency remained between 24 ms and 66 ms as upstream concurrency increased, confirming the architecture’s ability to handle high‑throughput messaging with modest delay.

Conclusion

The Go‑based IM service, built on a dual‑layer distributed model with clear separation of business logic, delivers stable, scalable, and high‑performance messaging for e‑commerce. Its flexible HTTP/WebSocket access, robust RPCX/ETCD infrastructure, and cloud‑native design make it a strong foundation for future growth.