Inside 58.com’s Mobile O2O Platform: Architecture, Evolution, and Push Tech

This article is a technical talk by Sun Xuan, system architect at 58.com, introducing the architecture and evolution of the company's merchant (mobile) management platform and sharing core O2O technologies.

58.com is a classified information website covering real estate, used cars, recruitment, yellow pages, etc. Its "58 Help" service includes IM and non‑IM business processing, handling over 1 billion IM requests and 3 billion business operations daily, with more than 1 million concurrent users.

58.com Help System Architecture

System Start: Traditional IM

Initially, the system was a traditional IM used for user communication and information transmission.

The architecture consists of four layers: access, logic, routing, and data.

Access Layer. Handles massive client connections from PC, mobile, and web, consolidating them into a few long connections and forwarding requests to the logic layer.

Logic Layer. Processes business logic such as permission checks, adding friends, and sending messages.

Routing Layer. Manages session‑related data (online status, login IP, etc.) that changes rapidly, storing it in memory rather than persisting.

Data Layer. Acts as a data middleware, abstracting differences between RDBMS and NoSQL databases for easier key data storage.

System Development: Third‑Party Business Integration

As business needs grew, the platform evolved from a pure IM system to a comprehensive merchant mobile management platform, integrating services like real estate and recruitment, enabling posting, refreshing, and pinning of listings.

Third‑party services are accessed via HTTP calls from the app, allowing rapid integration but creating tight coupling; any change in third‑party APIs forces client updates, leading to compatibility challenges and costly upgrades.

System Maturity: Client Lightweight

To mitigate coupling issues, an additional "Help WebService" layer was introduced, reducing client dependence on third‑party services.

O2O Core Technology Analysis

For mobile O2O, long connections, mobile LBS, and push technologies are crucial.

Push Main Approaches

Push is implemented through three primary methods:

Client polling (pull)

Clients periodically send queries to achieve push functionality. Pull is simple but has poor real‑time performance and high battery consumption when frequency increases.

SMS push

SMS messages are intercepted by a client module, parsed, and forwarded to the app. This offers good real‑time and delivery rates but is costly.

Server long connection (push)

The mainstream solution provides good real‑time performance with low battery impact.

Implementation on Different Platforms

Push implementations differ across platforms.

iOS platform

iOS does not allow background services, so push must use Apple’s APNS channel.

Android platform

Android offers more options, including Google’s C2DM, open‑source protocols like XMPP, and third‑party push products.

C2DM’s servers are overseas and can be blocked; many Android devices lack the module, making it unreliable in China.

Open‑source XMPP‑based push suffers from lack of ACK mechanisms and instability under high load.

Third‑party push services claim high delivery rates, but real‑world performance often falls short, and shared channels can affect real‑time delivery when other customers generate heavy traffic.

58.com considered building its own push solution but faced challenges such as managing massive server‑side long connections and ensuring client service stability on devices with limited memory.

Ultimately, 58.com combines multiple third‑party push services, selecting the best one per device type based on data analysis to improve delivery rates.