Improving Stability of Ctrip's Shark Multilingual Platform: Caching and File Redundancy Practices

Shark is a multilingual content management and delivery platform used by Ctrip's international business, supporting dozens of sites and thousands of applications.

The article outlines the platform's background, noting rapid growth in sites and business units, which increased data volume and complexity, prompting two major stability upgrades: caching and file redundancy.

The system architecture consists of five layers (application, SDK, interaction, service, storage), with the service layer comprising multiple micro‑services.

3.1 Initial stage (1.0‑2.0) – Simple architecture relying mainly on a database with read/write separation.

3.2 Caching construction (3.0) – As data volume grew, QPS approached 2k and DB network traffic peaked at 300 MB, leading to the design of a passive caching layer aligned with SDK polling intervals, achieving >90% cache hit rate and reducing DB pressure.

Key cache design considerations included near‑real‑time tolerance (1‑3 min delay), read‑heavy workload, request duplication, and the need for passive expiration.

3.2.3 Optimization results

Cache hit rate >90%.

DB peak traffic reduced from ~300 MB to ~40 MB.

DB QPS dropped from ~2000 to ~500.

Average response time decreased from 20 ms to ~3 ms.

3.3 File redundancy (4.0) – Addressed new stability issues introduced by cache reliance and strong client dependence on the server.

Server‑side redundancy uses Ceph for file storage, zip compression, and periodic generation of multilingual resource files, while client‑side redundancy injects resources via a custom Maven plugin during the prepare‑package phase and supports asynchronous updates at runtime.

Example Maven plugin configuration:

java
<plugin>
<groupId>com.ctrip.xxxx</groupId>
<artifactId>shark-maven-plugin</artifactId>
<version>x.x.x</version>
<executions>
<execution>
<goals>pack-download</goals>
</execution>
</executions>
</plugin>

Client‑side redundancy reduces server dependency by providing local fallback resources, with initialization during build and periodic asynchronous updates via the SDK.

The conclusion emphasizes that Shark remains a complex multilingual solution, with future work focusing on translation efficiency and broader machine‑translation support.