Architecture Evolution of the WeChat‑like Instant Messaging Service at 58 Group

Background: WeChat (微聊) is the instant‑messaging tool of 58 Group, serving products such as 58.com, Ganji, Mobile Agent, Anjuke, and Zhaocaimao across PC, mobile web, and app clients. To meet growing business demands, its architecture has undergone several versions and now forms a clear, layered micro‑service system.

Architecture Evolution

Initially the system used a very simple design: a single PHP service handled short‑connections, directly accessed the database, and shared a Redis store with the long‑connection service. The long‑connection service sent data downstream via an interface, while internal communication relied on internal HTTP calls.

This architecture had many problems: the short‑ and long‑connection services, although separated, shared storage, making changes to the store affect both services; HTTP communication was slower than RPC; the monolithic PHP codebase caused tight coupling, difficult collaboration, and complex version management; and PHP’s performance, combined with an inefficient framework, required excessive machine scaling.

To address these issues, the system underwent several service‑oriented refactorings, eventually achieving a clear, logical micro‑service architecture.

1. The long‑connection service was fully re‑implemented using 58’s self‑developed Java distributed RPC framework (SCF), eliminating shared storage, decoupling services, and improving performance over HTTP.

2. High code coupling was reduced by extracting business logic into separate services, enabling independent development without mutual impact.

3. Storage‑layer services were created for core data such as messages, sessions, user profiles, and friend relationships. These services switched from PHP to Java SCF and used the distributed storage system wtable, delivering significant performance gains. Data changes are published to a message‑queue, allowing downstream services to subscribe independently.

4. After storage services were isolated, the logic layer was further split. Independent services such as group management, anti‑spam, asynchronous tasks, and user‑profile synchronization were built on SCF.

The final architecture consists of three layers: the bottom storage layer (messages, user data, friend relations), the middle logic layer (anti‑spam, group services, long‑connection logic), and the top access layer (short‑connection APIs and long‑connection delivery channels).

5. Finally, internal and external interfaces were separated. An ImBusiness service was introduced to expose a unified internal RPC interface while keeping external APIs unchanged, improving both performance and usability.

After the PHP services became the main performance bottleneck, they were rewritten in Go for the short‑connection access layer. This rewrite reduced the total number of machines by 80%, lowered server load by over 50%, and cut key interface latency by at least 30%.

Key benefits of the final backend architecture:

Bottom storage uses 58’s self‑developed wtable distributed storage; business code no longer needs to handle sharding.

Data‑storage services are isolated, making schema changes transparent to upper layers.

Logic, interface, and storage layers are decoupled, so business logic changes do not affect external APIs or storage.

Interface layer is isolated for internal and external use; long‑ and short‑connection services cooperate to provide stable, reliable service.

Business Model

The article then illustrates two core business flows under the current architecture: user data synchronization and message delivery.

1. User Data Synchronization

User profile data (friend list, nicknames, avatars, etc.) is maintained by each business line. When a profile changes, the business line pushes the update to the messaging platform via an asynchronous message queue. The user‑profile sync service stores the data in wtable, and an asynchronous task service checks if the user is online via the long‑connection service; if online, the data is pushed immediately, otherwise it is delivered when the user next logs in.

This push‑pull mechanism provides highly real‑time user‑profile synchronization.

2. Message Sending

Message flow:

Clients call the short‑connection API, or business backends invoke ImBusiness/broadcast services to send a message.

The storage service persists the message and writes it to a message queue; the send‑API returns success.

An asynchronous task service processes the message: if the recipient is online, the long‑connection service pushes the message; if offline, a push‑notification service is used.

Online recipients acknowledge receipt via a short‑connection ACK.

Offline messages are delivered when the user logs in again, triggered by a login event on the long‑connection service.

Clients can pull historical messages via a short‑connection API after device changes or local deletions.

Business backends may subscribe to the message queue to replay the entire flow for analytics or further processing.

This collaborative module design ensures both reliability and real‑time delivery of messages.

Summary

The WeChat‑like service’s architecture has evolved through multiple iterations, balancing business requirements with technical compromises, and now features a clear, layered micro‑service structure with internal‑external isolation, data decoupling, and high performance. As 58 Group continues to grow, the architecture will keep evolving to meet higher performance and reliability goals.