Architecture Overview of the 58 Open Platform: API Gateway, Fault Tolerance, Rate Limiting, and Real‑time Messaging

Background: 58 Group, a leading domestic classified‑information website, serves numerous small and medium enterprises (SMEs). Many SMEs lack sufficient digital capabilities, limiting their growth. The 58 Open Platform leverages the group’s massive user base to expose powerful marketing and data capabilities to developers via APIs, notifications, and plug‑in services, enabling the creation of more competitive applications.

The platform is a crucial communication hub between 58 Group and external systems. Its technical architecture has evolved from an early monolithic, centrally deployed model to a modern design featuring single‑responsibility services, independent deployment, and decentralization, supporting multiple protocols such as API gateways, TCP push, degradation, and visualized monitoring.

The Open Platform handles massive daily API calls and message notifications, providing high‑availability, high‑performance interfaces that support the growth of multiple business lines within 58 Group. This article presents the key architectural points of the platform.

Overall architecture diagram:

Gateway and Fault Tolerance

The platform integrates numerous business lines, each exposing APIs with varied protocols (RPC, HTTP, ESB, etc.) and differing permission requirements. To safely expose internal data to external developers and enable rapid API integration and data transformation, an API gateway was built. The gateway employs a multi‑layer interface design, intercepting and processing incoming requests.

Two main processing steps at the access layer:

Defensive validation by the gateway: authentication, rate‑limiting, degradation, and data correctness checks.

Gateway dispatch: the gateway parses protocols based on registration‑center data, dynamically constructs invocation examples, and performs generalized service calls.

Gateway Authentication

Internal data is distributed across independent business systems. To expose this data securely, the API gateway offers multiple authentication schemes.

OAuth2

OAuth2 authorizes whether a developer’s system has permission to act on behalf of a user (e.g., posting on the user’s behalf). The flow is as follows: the user accesses the developer’s application, which redirects to the 58 authorization page; after the user grants consent, 58 returns an authorization code, which the developer exchanges for an access token.

Symmetric Encryption

This scheme applies to generic capability APIs (e.g., housing price evaluation, image moderation, semantic recognition) that do not involve user‑level consent. After a developer registers on the 58 developer site and creates an APP, the system assigns an APPKEY and APPSECRET. Requests must sort parameters and generate a signature (SIG) using APPSECRET as the key; the platform validates the SIG for authentication.

Token

Token authentication supplements symmetric encryption for scenarios where a third‑party platform wants to grant permissions to external devices (e.g., mobile clients) without exposing the secret key.

The developer requests a token from the authorization server using APPSECRET, receives a token, and the external device includes the token in API calls. The platform validates the token, allowing fine‑grained control over API permissions, expiration, and usage limits.

Gateway Smooth Rate Limiting

Different business lines have varying service capacities; to ensure stable service and prevent overload, the gateway implements multi‑dimensional smooth rate limiting.

Implementation uses Redis + Lua to realize a token‑bucket algorithm with second‑level granularity. When a request arrives, the system derives a unique rate‑limit key (e.g., prefix_apiid_appid), determines the time granularity and limit, and uses a Lua script to fetch and possibly replenish tokens.

Gateway Circuit Breaking and Degradation

When backend calls timeout or encounter exceptions, continued requests are futile. The gateway therefore employs circuit breaking: once error thresholds are reached, further calls are rejected immediately. The platform uses Hystrix, opting for semaphore isolation (instead of thread pools) due to the large number of APIs and groups, reducing thread overhead. Each API can be configured with error‑rate or failure‑count thresholds for automatic degradation.

Isolation

APIs have diverse requirements for throughput, latency, data size, and concurrency. Co‑locating services with different characteristics can cause mutual interference, and failures in one service may affect others. To mitigate this, the platform introduces thread‑pool isolation, assigning separate thread pools to API groups based on weight, ensuring that issues in one group do not cascade to others.

Technical details: the system creates multiple thread pools per API group; incoming requests are dispatched to the appropriate pool. If a particular API fails, only its group’s threads are affected.

Real‑time Message Push

Real‑time push is a core component of the 58 Open Platform. Traditional polling is inefficient and wasteful. The platform implements a Netty‑based keep‑alive NIO model, supporting nearly a million concurrent connections, delivering timely notifications to third‑party developers.

It uses a unified ESB asynchronous entry, isolating traffic by topic per business line, preventing high‑volume services from blocking others. An RPC interface complements ESB for business lines that cannot use ESB, allowing developers to call SCF interfaces for message push.

The message system employs a broker‑based distribution model with modular plug‑in processing, making new message source integration extremely simple and shortening development cycles.

Based on Netty, the architecture builds a massive push model, using keep‑alive long connections to handle the entire receive‑push‑acknowledge flow asynchronously.

Summary and Outlook

Due to space constraints, many technical details such as link‑call logging, Kafka‑Storm‑ES data statistics, and alerting are not covered.

The platform has made significant progress in performance, stability, and content richness after more than a year of development.

Future plans include introducing a service marketplace, component‑based construction, enriching integration endpoints, supporting mini‑programs and H5, and adopting serverless to further open and share the company’s technical capabilities and resources.