Migrating Ctrip Hotel Search Engine to AWS: Challenges and Practices
This article details Ctrip's experience migrating its high‑traffic hotel search service to AWS, covering microservice architecture challenges, API‑level deployment, persistence strategies with Redis, MySQL, XPipe and DRC, file sharing via S3, and lessons learned for future cloud‑native designs.
Authors: Miyuan (Ctrip senior backend engineer) and Spike (Ctrip senior backend specialist).
With Ctrip's rapid international expansion, the hotel search engine—a core user‑experience component—needed to move to the cloud. The article walks through the full HTTP request flow from the Trip app through the gateway, internal microservices, and various persistent stores.
1. Challenges of Microservice Architecture The popular “Staycation Deals” feature touches over a hundred downstream services in the BAT monitoring system. Migrating every dependency to the cloud is impractical, so the team investigated API‑level dependencies and discovered that the hot API only relies on eight services.
Using Ctrip's internal release system TARS, which integrates with AWS, Alibaba, etc., they deployed the selected services via a unified UI. After deploying nine applications, two major issues emerged: the gateway could only route traffic by service, not by API, and cross‑IDC access to Redis/MySQL was blocked for security reasons.
2. Cloud Persistence The core API still required two Redis instances and one MySQL instance. Direct inter‑IDC links proved too latency‑sensitive, so the team deployed these stores in each AWS IDC. They replaced Redis with the open‑source KV store Trocks and used XPipe for one‑way Redis replication. MySQL replication leveraged Ctrip's DRC component, using its single‑direction mode.
Replication latency stayed within a few hundred milliseconds, meeting expectations.
3. Cloud File Storage and Sharing The search engine reads and writes large local files (up to 10 GB). Initial attempts to share files via dedicated lines failed due to bandwidth and reliability issues. Switching to AWS S3 for cross‑IDC file sharing succeeded and met performance needs, though it introduced vendor lock‑in concerns. Ctrip mitigated this by providing an internal JAR that abstracts cloud storage APIs.
4. Summary Thanks to prior infrastructure work by Ctrip's platform team, the migration was feasible. The experience highlighted the importance of API‑level dependency analysis, unified deployment tools, and cloud‑native persistence solutions. Future architecture designs now routinely consider cloud‑readiness and multi‑cloud deployment from the start.
Ctrip Technology
Official Ctrip Technology account, sharing and discussing growth.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.