Discussion on the solution of 12306 (transfer)

I think the business design of 12306 has gone astray. From its launch to this year, it has been working on the real-time ticket purchase business. People use 12306 to compare with platforms such as Taobao, but in fact, this is not necessarily the case. Because they understand that there are problems in the high-pressure ticket purchasing business of the Spring Festival.

　　First of all, we say that tickets for the Spring Festival are reserved tickets. They are first reservations. Therefore, they could have solved the problem without the business model of buying tickets in real time, but they chose to use the business model that is the most difficult and difficult to control. Think, their business experts, got water in their heads. . .

　　Why can't it be made into a volunteer type similar to the college entrance examination? That is, fill in the ticket purchase intention, and the back-end server automatically calculates the allocation, and adopts a similar lottery strategy to deal with the shortage of tickets; anyway, the tickets are originally insufficient, and it is impossible to maintain absolute fairness. ; It is better to be more elegant, fill in the ticket purchase intention, and wait for the back-end calculation, regular notification is better than letting everyone rush to grab it without thinking, and it is easy to design and implement;

　　the back-end calculation and distribution of tickets, in terms of system pressure, is more than tens of millions of people rushing in real time. Tickets are much lower, occupy less resources, and are easy to test and implement. They can completely simulate the test by themselves, just data calculation, unlike now, it is very difficult to simulate tens of millions of people online to grab tickets, even if There are stress testing tools, but they are inaccurate. Stress testing tools cannot fully simulate business operations; moreover, they can also have the energy to study and improve the ease of use of ticket purchases. Now they are all focused on how not to crash and how to deal with robberies. On the ticket software, there is no business at all! It's not that the user's use is easy and smooth. I don't know why those so-called experts do not adopt this strategy, probably because they are not short of money.

　　In this way, this centralized ticket purchase can be brought back to its essence, the business is booked, and then the real-time ticket purchase business within a few days is reserved. That business is basically a loose ticket, and it can be limited to purchases only at stations and sales points, etc. Wait for business rules to avoid situations such as ticket swiping and reduce system pressure.

　　Focus on how to adjust the user's reservation strategy, so that users can enter their reservation intentions more smoothly and ideally, and wait for the system to notify based on whether the ticket is booked. ?

　　As for fairness and black-box operation, even the current real-time ticketing system cannot guarantee fairness, let alone avoid black-box operations, because you can't see the back; if you use ticket-swiping software, you have higher priority, but it's unfair. . It is more fair to use background services to calculate distribution. Whether migrant workers or programmers, everyone is really equal, and you do not need skills that have nothing to do with ticket purchases. . . For migrant workers, it would be fairer if the Ministry of Railways provided a proxy entry service, or it would be better if there were public service organizations serving them.

　　I hope that 12306 people will see my speech and think about whether there is a problem with your business model? Is there any deviation in your research direction, save some money for the country, please.

　　If there are not enough tickets, no matter what you do, everyone will not be satisfied. However, you should also make everyone feel comfortable to buy tickets. Anyway, there are always some that cannot be bought, right? . . Now it has become a second ticket, which is a mess. . .