Why 12306 Shows Seats Yet Blocks Purchase: Inside Its Complex Inventory Logic

During long holidays many users try to buy train tickets on 12306, only to encounter the frustrating situation where the app shows an available seat but then reports insufficient tickets when submitting the order.

The official 12306 page lists common reasons for this mismatch:

Simultaneous booking attempts by multiple travelers for the same limited seats; the first request wins, leaving later attempts without tickets.

Network failures that prevent the booking request from reaching the server.

Other unknown issues; users are advised to retry later or contact the service hotline if the problem persists without any official maintenance notice.

The fundamental cause is that the data shown by the app can be “dirty.” 12306’s seat‑deduction process is far more complex than typical e‑commerce inventory handling. The system divides a train’s route into intervals (A, B, C, D, E) and manages ten possible ticket‑selling scenarios across these segments.

When a passenger purchases a ticket for a specific segment, such as B‑to‑C, the system must decrement the available seat count not only for B‑C but also for all larger intervals that include B‑C (A‑C, A‑D, A‑E, B‑D, B‑E). Intervals that do not contain the purchased segment (A‑B, C‑D, C‑E, D‑E) remain unchanged. This “one‑ticket affects many intervals” logic makes inventory management highly intricate.

Because millions of users query ticket availability simultaneously, real‑time calculation of every interval’s remaining seats would overwhelm the servers. Therefore, 12306 stores seat counts in a cache for fast reads, while the actual deduction occurs in the primary database and is later synchronized back to the cache.

This design speeds up queries and reduces server load, but it also introduces a lag: the cached data may not reflect the most recent purchases, leading to the “visible but not purchasable” scenario.

Shorter cache refresh intervals improve accuracy but increase computational pressure; longer intervals reduce load but raise the risk of stale data.

During peak periods such as Spring Festival or National Day, a possible optimization is to lock middle‑segment tickets and prioritize selling full‑route (A‑to‑E) tickets first, simplifying the inventory calculation and accelerating cache updates.

The current pre‑sale system for 12306 also follows a similar principle, releasing tickets for different segments in advance to distribute load and improve overall booking efficiency.