How 58.com Scaled Its IM Platform: Four Architecture Evolution Stages

Abstract: 58.com, China’s largest life‑service platform covering real‑estate, recruitment, classifieds, and more, uses the 58‑BangBang service to enable communication between users and merchants. The article examines how 58‑BangBang’s architecture has continuously evolved since launch to handle billions of daily requests and over one million concurrent users.

58‑BangBang consists of an instant‑messaging (IM) component and non‑IM business processing. It now processes over 1 billion IM requests and 3 billion non‑IM requests daily, exceeding 4 billion total requests, with concurrent online users surpassing one million.

Stage One: Traditional IM

Initially, 58‑BangBang was a classic IM system supporting user‑to‑merchant communication via PC desktop, web, and mobile clients. The architecture (see Figure 1) is divided into five layers:

Entry Layer

The entry layer handles massive long‑connection requests, establishes encrypted channels, compresses data, forwards requests to the logic layer, and implements basic security measures such as IP/UID black‑white lists.

Logic Layer

Implements core business logic for user management, friend operations, and message handling, including offline messaging.

Router Layer

Manages session‑related data (online status, login IP) in memory and records routing information for targeted communication.

Data Access Layer

Provides a unified interface to underlying storage (RDBMS, NoSQL, KV), abstracting CRUD operations.

Data Storage Layer

Persistently stores data using MySQL, MongoDB, and caches with Memcached/Redis.

The layered, stateless design allows dynamic scaling, redundancy, and high availability, supporting 500 k+ concurrent users per node and over 30 k QPS.

Stage Two: From Traditional IM to Merchant Management Platform

As product scope expanded to include classifieds, recruitment, and real‑estate, 58‑BangBang evolved into a merchant management platform. New features required HTTP‑based calls to third‑party services, reducing reliance on long connections but introducing tight client‑service coupling and upgrade challenges.

To mitigate this, an intermediate server layer was added (see Figure 3), routing all third‑party requests through 58‑BangBang’s backend, making client upgrades transparent. However, this introduced longer request paths (five subsystem hops) and higher latency, and still relied on TCP long connections for mobile clients.

Stage Three: From Merchant Management to Mobile Marketing Tool

The platform further transformed into a mobile marketing tool for merchants, adopting lightweight WebService calls over HTTP. This reduced client‑side dependencies, cut network interactions to two hops, improved latency, and simplified troubleshooting.

The final architecture separates IM (still using TCP long connections for real‑time messaging) from third‑party business services (using HTTP short connections), balancing performance and user experience.

Stage Four: Building a Mobile Push System for 58‑BangBang

To address mobile network instability and app reachability, three push strategies were evaluated:

Client polling (pull) – simple but high latency and resource consumption.

SMS push – reliable but costly.

Server‑maintained long‑connection push – real‑time, low power, but complex.

Implementation details for iOS (APNS) and Android (C2DM/XMPP and third‑party services) are illustrated in Figures 5 and 6. Challenges include server accessibility, reliability, and platform fragmentation.

Ultimately, 58‑BangBang adopted a hybrid solution combining third‑party push providers with a custom high‑performance provider (see Figure 7), achieving hundred‑billion‑level daily throughput and dynamic push strategies to maximize delivery rates.