Domain Modeling and Architecture Design for High‑Concurrency Train Ticketing System (12306)

Motivated by the observation that the 12306 ticketing system is far more complex than typical e‑commerce sites, the author argues that proper business analysis and domain modeling are essential for such a high‑concurrency application.

The core requirements include ticket query, ticket purchase (booking and payment), and railway authority ticket issuance, all revolving around train journeys.

By treating each ticket as a travel interval, the author shows that a single train can generate hundreds of SKU‑like tickets, and that overlapping intervals must respect a rule: the sum of overlapping counts plus one cannot exceed the train's total seat count.

Consequently, the train (or train service) is modeled as the aggregate root, holding seat numbers, station sequence, and atomic segment inventories, thereby guaranteeing strong consistency for ticket issuance within a single aggregate.

Two seat‑allocation strategies are discussed, and the author recommends a “reuse‑first” algorithm that selects already‑occupied seats for new intervals to avoid mid‑journey seat changes.

The analysis concludes that tickets are merely issuance results, while the train aggregate handles availability checks, seat selection, inventory updates, and sold‑ticket tracking.

For the overall system, a CQRS architecture with event sourcing (e.g., using the ENode framework) is suggested, allowing the train aggregate to reside in memory, process commands without database transactions, and emit a single JSON event per booking.

Querying remaining tickets can be efficiently served by distributed caches, with key designs based on departure, destination, and date, enabling near‑real‑time updates via event‑driven synchronization.

Finally, the author emphasizes that deep domain modeling, collaboration with domain experts, and careful architectural choices are crucial for building reliable, high‑throughput ticketing systems.