Design Principles and Architecture Evolution of Ctrip Business Travel Order System

Overview: Ctrip Business Travel is a one‑stop online travel management platform offering services such as ticketing, hotel booking, ground transport, and expense control. Its order system serves B‑end customers and must handle diverse customization, rich product lines, and complex integration.

Background: The order system is the entry point that links order lifecycle, TMC control, creation center, expense center, fulfillment, service, aggregation, and complaint handling. It can be examined from customer dimensions (employee, finance, audit) and platform dimensions (account configuration, order aggregation, API integration, supplier management).

Problems of the original vertical‑only architecture include lack of a unified workflow engine, tight coupling between subsystems, duplicated functionality across product lines, heavy DB load, coupled online/offline scenarios, and insufficient monitoring and compliance.

Design principles based on business characteristics:

Layered design – treat the B‑end system as a C‑end core and add B‑specific logic via independent services, enabling configurability and plug‑in orchestration.

Process design – extract commonality across product lines, provide a standardized, configurable workflow engine, and abstract order states and events.

Snapshot design – persist travel control information (account config, payment accounts, approval policies) for each transaction to support auditing, complaint handling, and traceability.

Architecture evolution:

Order Consolidation – abstract data into fact and dimension tables, reduce DB pressure, and provide near‑real‑time query capabilities.

Order Message – a configurable message center that abstracts various notification scenarios into plug‑in “scenes”, reducing client‑side logic.

Order Conductor – service orchestration with atomic tasks, data isolation, contract‑driven communication, event‑driven workflow, idempotency, retry mechanisms, and DB access throttling.

Order Fulfillment – state‑driven, configurable workflows that handle the combinatorial explosion of B‑end order attributes and statuses.

Conclusion: Good design minimizes what must be done, maximizes automation and standardization, separates vertical (custom, fast‑changing) and horizontal (stable, reusable) concerns, and avoids over‑centralized “middle‑platform” pitfalls.