最近在微博上對12306億元招標的議論很多，技術類帳號很多都認爲用那麼多錢做出如此訪問速度和操作效果的站點實在不應該。很多人提出了各種各樣的解決方案，而這些方案大多來自互聯網電商的實現架構，例如淘寶應對雙11或京東商城與蘇寧價格戰中對海量訪問支持方案等。但是似乎大家忽略了一個問題，鐵道部的互聯網訂票系統是在已有車票票務系統基礎上發展起來的。從鐵道部的新聞稿中可以看出，目前的車票票務訂票系統已經開發了盡10年時間。在系統開發的大部分時間裏，都是以滿足各車站訂票窗口和分佈在大中城市裏的訂票點使用作爲目標。這樣一套系統的訪問終端數量可控，訪問終端的刷新頻率可控。如果這套終端系統是C/S結構，客戶端只需要從票務數據庫服務器中獲取少量數據就可以進行大部分查詢操作，然後在最終訂票時對數據鎖定做寫操作就可以。這套系統的成功應用使我們可以在全國任何一個售票窗口買到任何車次任何城市出發的車票，然而也正是這套系統的存在使得12306在實現互聯網訂票上變得舉步維艱。
首先12306的功能實現一定不能影響到現有車票票務系統的使用，如果12306與現有票務系統的數據分離存儲，這兩部分數據之間的同步，實時大併發下兩部分數據寫操作鎖的實現都會成爲難點。所以不妨大膽猜測一下，12306系統訂票寫操作與現有票務系統訂票寫操作訪問的是同一中央數據庫，而爲了保證現有票務系統對數據庫訪問速度，來自12306系統的鏈接數是有最大值限制的，而且此最大值是遠遠低於安全閥值的。如此一來如果中央數據庫的處理能力得不到提升，12306在WEB端做的任何努力都是無意義的。
如果以上前提成立，那麼爲了中央數據庫的安全考慮，12306的主服務器應該就在鐵通的網絡裏，國內網絡運營商之間的互連互通做的如何，大家都是有目共睹的。所以網絡原因也會大致很多用戶在訪問12306時反應緩慢。
這種狀況下最簡單的處理方式可能就是下血本去更換高處理能力的數據庫服務器，提高數據庫存儲和操作的計算能力，以滿足海量高併發訪問請求。但是這樣投入的資金可能會是天文數字但是卻收效甚微。而另外的做法就是從數據庫的結構上做調整，滿足海量併發請求操作，但是如此底層修改可能會牽扯到現有票務系統的修改，12306與現有票務系統是否爲同一家企業開發實現不得而知，對現在已經正常運行並且已經通過某某驗收獎勵的系統做出重大更改，可能也是鐵道部所不願意的。
所以如果一定要下一個結論的話，那就是12306這個海量事務高速處理系統並不如大部分人設想的那樣很容易就可以實現。即使鐵道部真的如大家希望的那樣公開招標，引入其他有經驗的開發企業，當這些企業進駐時會發現，有些並不僅僅是技術實現的問題。