最近有朋友問我，說我的文章里，總是提“脫離業務的架構設計是耍流氓”。

每次都是架構根據業務折衷，有沒有業務和產品由于技術難度太大來做折衷的?

當然有，當一個業務技術難度非常大的時候，可以通過業務和產品的優化，來簡化系統架構。

[[233838]]

以“12306車票秒殺”為例，秒殺業務架構難度大，業務和產品可以這么折衷：

case 1

一般來說，下單和支付放在同一個流程里，能夠提高轉化率。

對于秒殺場景，產品上，下單流程和支付流程異步，放在兩個環節里，能夠降低數據庫寫壓力。

12306，下單成功后，系統占住庫存，45分鐘之內支付即可。

case 2

一般來說，所有用戶規則相同，體驗會更好。

對于秒殺場景，產品上，不同地域分時售票，雖然不是所有用戶規則相同，但能夠極大降低系統壓力。

北京9:00開始售票，上海9:30開始售票，廣州XX開始售票，能夠分擔系統壓力。

case 3

秒殺場景，由于短時間內并發較大，系統返回較慢，用戶心情十分焦急，可能會頻繁點擊按鈕，對系統造成壓力。

產品上可以優化為，一旦點擊，不管系統是否返回，按鈕立刻置灰，不給用戶機會頻繁點擊。

case 4

一般來說，顯示具體的庫存數量，能夠加強用戶體驗。

對于秒殺場景，產品上，只顯示有/無車票，而不是顯示具體票數目，能夠降低緩存淘汰率。

顯示庫存會淘汰N次，顯示有無只會淘汰1次。更多的，用戶關注是否有票，而不是票有幾張。

...

無論如何，產品技術運營一起，目標是一致的，把事情做好，不存在誰是甲方，誰是乙方的關系。

脫離業務的架構設計是耍流氓。

架構難度大，產品也應該折衷。

畫外音：秒殺業務的架構優化講過了，這次說產品上的優化。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文