Evolution and Refactoring of the Mafengwo IM System: From PHP 1.0 to Go‑Based Microservices

As Mafengwo’s travel content and commerce grew, its instant‑messaging (IM) system became a critical channel for users to ask questions, receive answers, and complete transactions, prompting several major architectural revisions.

IM 1.0 – Early Stage : Built with PHP, the system offered basic user‑to‑customer‑service messaging. Messages were placed into Redis blocking queues, and a long‑polling HTTP connection fetched them, using a simple average‑distribution strategy for assigning users to agents.

Message Polling Optimization : To avoid PHP‑FPM processes being blocked by many long‑polling requests, the polling module was rewritten with OpenResty and Lua coroutines, which intercept requests, offload blocking work to Lua, and promptly release PHP‑FPM processes.

IM 2.0 – Customization Phase : Rapid business growth introduced many custom features. The system added multiple assignment strategies (average, weighted, queue), automatic replies, FAQs, and richer consultation flows, while still using the PHP‑based message pipeline.

IM 3.0 – Service Splitting Phase : Codebase bloat, tangled responsibilities, and high coupling forced a service‑oriented redesign. The monolith was split into four major services: Customer Service, User Service, IM Service, and Data Service.

The Customer Service service handles group management, quality inspection, and intelligent routing; the User Service provides behavior analysis and satisfaction metrics; the IM Service supports one‑to‑one and group chats, offline push, history, file upload, and content moderation; the Data Service aggregates consultation metrics such as response time, conversion rates, and workload.

User State Flow : A diagram illustrates the lifecycle from initial consultation, assignment, resolution, to automatic closure, highlighting state transitions (initial → pending assignment → assigned → resolved).

IM Service Refactoring : To reduce dependencies and improve scalability, the IM service was rewritten in Go. The new architecture introduces a Proxy layer and an Exchange layer. The Proxy handles routing (IP‑hash, round‑robin, least‑connections), client connection management, and the WebSocket protocol. The Exchange layer provides REST APIs for single‑ and group‑message delivery and coordinates inter‑instance communication via RPC.

Message flow after refactor: PHP creates the message line and assigns an agent; the Dispatcher looks up the target ChannelManager via a shared DispatcherTable (stored in Redis), forwards the message via RPC, and the ChannelManager pushes it to the client over WebSocket. Scaling is achieved by adding ChannelManager instances, with ETCD notifying listeners for seamless expansion.

Key Design Considerations in the Exchange Layer :

Routing rules (IP‑hash, round‑robin, least connections) to distribute clients across ChannelManager instances.

Connection metadata stored in DispatcherTable (uid, unique field, wsid, client IP, server IP, channel) with a 2‑hour TTL to avoid stale entries.

Online status synchronization: push notifications to online agents only when a user comes online, avoiding excessive polling.

Message reliability: for long‑polling, the client sends the last read message ID; for WebSocket, the server expects ACKs and retries on failure, while the client deduplicates based on message IDs.

Message Flow and DDD Modeling : Using Domain‑Driven Design, messages are processed differently based on domain, device, and role, ensuring that notifications are tailored appropriately.

Summary and Outlook : The IM system has progressed from a simple PHP prototype to a robust, Go‑based micro‑service architecture that supports high concurrency, multi‑device synchronization, and reliable messaging. Future work includes replacing the remaining polling service with Go, and leveraging TensorFlow to build intelligent customer‑service assistants.

Author : Mafengwo E‑commerce Platform IM R&D Team.