Evolution Stages and Architecture of Mobile Taobao: API Gateway, Bundles, WebApp, and Support Systems

Since 2009, Mobile Taobao's daily active users (DAU) grew from 1 million to over 100 million, prompting four distinct architectural evolution stages.

Stage 1: The predecessor of Hand Taobao, a WAP site, required rapid releases using HTML templates and a single application, allowing changes without backend code modifications.

Stage 2: Rapid DAU growth introduced multiple platforms (WAP/Android/iOS) and the need for a unified API gateway to replicate and manage business logic across them.

Stage 3: Further DAU increase brought more online systems and diverse business needs, leading to a full HTML5 solution, mixed HTML5‑Native services, and an optimized, extensible API gateway.

Stage 4: When DAU reached 100 M, the API gateway was deployed across many IDC rooms, requiring systematic architecture governance for effective development, integration, and monitoring.

API Gateway

Initially there was no API gateway for WAP; as the number of applications and exposed APIs grew, a unified gateway became necessary to simplify management and avoid complex coupling.

With DAU growth, the gateway risked becoming a single point of failure. The backend connects many applications through the gateway, which theoretically has no call limit as long as memory and network bandwidth suffice. A wide‑area gateway mechanism and a custom RPC system were introduced to decouple services and handle dynamic backend changes.

The gateway also adds security, auditing, logging, and other functions. In later stages, multi‑IDC deployment and centralized control of API gateways support large events like Double‑11/Double‑12, allowing the app to query a central gateway for the appropriate regional gateway.

In this model, the app asks the central gateway which real API gateway to use; the central gateway responds, and the app then connects to the regional gateway to invoke backend services, all under unified management.

Mobile Side

1. Bundle

In the second half of last year, the Mobile Taobao architecture was reorganized. The runtime architecture (left) and the engineering code structure (right) show that business teams provide deployable bundles containing UI, services, and middleware calls. A main thread manages a unified UI service bus, and a runtime container runs all bundles. For example, the Juhuasuan team develops its own project, packages it as a bundle, and ships it together with others.

2. WebApp

The current Mobile Taobao HTML5 framework consists of a custom HTML5 runtime container that runs various WebApps. A unified publishing system performs performance checks (CDN compliance, HTML validation, etc.) and security/audit reviews before pushing content to the CDN. The container receives runtime instructions, updates configurations, loads new WebApps, handles URL navigation interception, and supports interactive features.

3. PackageApp

The newest construction, called PackageApp, builds on the previous system but hides the download process from users. HTML5 and WebApp resources are pre‑cached on the client; when a user clicks an icon, the system checks for a newer version on the CDN and asynchronously updates if needed, all managed by a unified release platform.

PackageApp emphasizes three aspects: standard URL navigation, a container‑defined specification for WebApp development, and adaptive update strategies for different network conditions (Wi‑Fi vs. cellular, full vs. incremental updates).

The LoadTime comparison before and after adopting PackageApp is shown below:

Support System

1. R&D Support

R&D support includes code review, unified UI libraries, daily pre‑release environments, and online “coloring” clusters for targeted testing. After pre‑release, code is pushed to production, and a coloring cluster isolates problematic users for detailed analysis without affecting the entire user base.

2. Testing Support

Testing covers unit tests, stability, performance, and automation. With a monthly release cycle, automated API regression tests are run against the unified gateway, and client‑side scripts verify that new code does not break existing functionality. Static code scanning also prevents low‑level issues.

3. Operations Support

Mobile operations differ from web operations, focusing on performance, stability, business monitoring, and especially sentiment monitoring. Since mobile apps are distributed through many app stores, real‑time sentiment analysis aggregates user feedback from the app, markets, and social media to identify critical issues.

4. Release Support

Release support enables flexible rollout strategies such as internal gray releases, targeted user groups, regional deployments, and data‑driven version targeting. Critical issues can be fixed quickly by replacing bundles or applying hot‑patches (class‑loader based patches on Android, with iOS solutions under exploration).

During a major promotion, a severe issue was resolved via a hot‑patch rather than a full bundle replacement due to the massive download volume and limited time.

Client Monitoring

Minute‑level metrics capture success count, failure count, and failure rate of user actions, providing real‑time business availability monitoring.

Public Opinion Platform

The platform collects feedback from the app, app stores, and social media, aggregates it, performs keyword clustering, and classifies topics (e.g., payment, detail, refund). This enables rapid issue identification, user outreach, and data‑driven product improvements. Over time, the platform’s data feeds big‑data analysis to automatically evaluate the impact of technical changes.

(Source: InfoQ)