Evolution of Ctrip App Architecture: From Early MVC to Modular API Gateway and Dynamic Plugin Loading

Author Introduction Nan Zhiwen, R&D Manager of Ctrip Hotel R&D, previously worked at Alibaba and Giant Network. The article first appeared in Programmer magazine.

Introduction Over 75% of Ctrip orders come from mobile, making the App the core of the business. The article explores how the wireless backend and client architecture have been refactored to support complex, rapidly changing business needs while enabling dozens of development teams to collaborate within a single App.

App Server Architecture Evolution

Early Server Architecture (V1) The initial backend extended a PC Web application with REST interfaces for the App, leading to strong coupling, duplicated effort, and stability issues.

Strong Coupling : Changes in the Web side affect the wireless APIs and vice‑versa.

Duplicate Work : Each backend service had to implement common features (security, logging, monitoring) separately.

Stability : Direct connections between the App and multiple backends caused a single failure to affect the whole App.

Server Architecture V2.0 – API Gateway To address the above problems, Ctrip introduced an API‑Gateway‑based architecture with three main characteristics:

Peer Isolation : The App has its own independent server, decoupled from the PC web server.

Unified Services : Core logic is extracted into services shared by both PC and wireless clients.

Unified Gateway : All App requests go through a single gateway that provides protocol adaptation, security, logging, rate‑limiting, isolation, circuit‑breaker, and anti‑scraping.

The gateway is built on open‑source Netflix projects such as Zuul, Archaius, Hystrix, and Eureka.

Intelligent Upgrade/Downgrade The gateway monitors request failure rates and automatically reduces traffic to problematic interfaces, gradually restoring traffic when stability improves. This prevents a single faulty service from degrading the whole system.

Client Architecture Evolution

Early Client Architecture (V1) The first App version (2011) used a classic MVC structure with a data‑service layer. As the codebase grew, the Controller layer became massive and tightly coupled, leading to maintenance difficulties.

Client Architecture V2.0 To solve method‑count limits (65535) and memory constraints of early Android versions, Ctrip adopted a hybrid approach: core features (hotel, flight) remained native, while less‑used features were moved to H5 containers. Multi‑Dex and code‑clean‑up further reduced method counts.

Dynamic Dex Loading Inspired by Facebook’s multi‑Dex solution, Ctrip implemented a custom loader that splits the APK into multiple Dex files and loads them at runtime. The loading logic runs in a background thread to avoid ANR. Example snippet: android:name="com.facebook.nodex.startup.splashscreen.NodexSplashActivity"

Client Architecture V3.0 – Bundle Plugin Framework Building on V2.0, Ctrip introduced a bundle‑based dynamic plugin system (DynamicLoader) that supports instant, on‑demand, and remote loading of modules. Over 30 bundles (e.g., hotel, flight, train) are integrated into the main APK, each with its own version and isolated resources. The framework also provides hot‑fix capabilities similar to Alibaba’s AndFix.

Future Direction (V4.x) Ctrip is exploring native‑to‑web‑style deployment, cross‑platform native experiences, and sub‑second build times for dozens of bundles, aiming to further improve developer productivity.

Conclusion

A well‑designed architecture must solve concrete technical problems, follow solid design principles (DIP, LSP, ISP, etc.), and evolve with business needs. Ctrip’s journey from monolithic MVC to a modular, plugin‑driven ecosystem illustrates how systematic refactoring and progressive adoption of industry‑proven patterns can sustain large‑scale mobile products.