Hybrid Cloud Architecture and Scalability Analysis of China’s 12306 Railway Ticketing System

The introduction highlights the massive traffic generated by Chinese New Year activities such as "Shake" interactions on WeChat and Alipay, emphasizing that behind the apparent promotional gimmick lies a need to showcase the value of mobile payments and the technical challenges of handling billions of requests.

From a technical perspective, the article argues that high‑traffic, high‑concurrency scenarios like 12306 require advanced cloud and big‑data technologies; building a dedicated on‑premise system for short‑term peaks is costly, whereas a hybrid‑cloud model can provide flexible, on‑demand resources.

Section 1 compares 12306 with typical e‑commerce platforms, noting that while both involve login, browsing, ordering, and payment, 12306’s ticket‑inventory logic is far more complex. Each ticket sale affects the dynamic availability of seats across an entire route, requiring intensive CPU calculations and real‑time updates, unlike the static inventory of most online stores.

Section 2 discusses the factors influencing a hybrid‑cloud design for 12306, including hosting scope, data security, subsystem independence, data synchronization, and elastic resource scaling. It concludes that the seat‑availability query subsystem, which consumes the most CPU and network resources during peak periods, is the prime candidate for public‑cloud deployment.

Section 3 speculates on the actual hybrid‑cloud architecture used in 2015, describing two production centers (the railway’s data center and the research institute’s data center) and a rented public‑cloud component (Alibaba Cloud) that handles roughly 75 % of query traffic. The design includes high‑availability dual‑center operation, disaster‑recovery replication, and dynamic scaling of the query service.

Section 4 summarizes the overall two‑site three‑center hybrid‑cloud deployment, emphasizing partial business outsourcing, strict protection of personal data in the private cloud, continuous service through parallel data‑center operation, and the combination of NoSQL (Gemfire) for hot data with relational databases for persistent storage.

The article concludes with four recommendations: enable multi‑segment itineraries, centralize data processing, integrate online and offline ticketing channels, and adopt software‑defined data‑center technologies to further improve flexibility and disaster‑recovery capabilities.

Hybrid‑cloud hosting considerations

Security and data‑privacy concerns

Elastic resource scaling for peak traffic

High‑availability and disaster‑recovery design

Support for combined‑carriage tickets

Data‑centralization to reduce exchange overhead

Integration of online and offline ticketing systems

Adoption of software‑defined data‑center techniques