前年我在一間直播代購電商新創擔任 Backend Lead:客人在直播留言「2601+1」就是下單——起標瞬間每秒 200 則留言、13,000 人在線,而全部家當是一台 VM、一顆 Cloud SQL 和六個工程師。這 30 天不是回憶錄,是帶著現在功力的完整重打:每天從一個真實需求出發——留言怎麼變成訂單、庫存怎麼守住不超賣、金流三個坑怎麼被架構整組溶解、沒有 SRE 的年代怎麼靠人肉跟播——先誠實講當年怎麼做、踩了什麼,再給出重來版設計。從第一行程式、開賣尖峰、真實事故,一路寫到拆成微服務與終局:一個真實系統的軟體開發實錄。改寫自我的部落格同名系列。
Day 9 把單聚合成了三層、昨天拔掉了狀態機,現在要收錢了。金流是這個系統第一次把「正確」交到別人手上——付款發生在銀行那邊,你只能透過不可靠的網路得知結果。...
昨天留了個懸念:教科書的三個坑(重複、亂序、失蹤),當年一個都沒踩。今天把原因攤開。 沒有坑的地形 當年的系統,這三個坑的體感是:「好像沒遇到什麼問題」。把昨天...
錢收完了,該出貨了。這章是系統與實體世界的交界——留言、庫存、金流都活在資料庫裡,但貨是真的紙箱、真的倉庫、真的宅配司機。也因此,這是全系列「系統邊界」劃得最有...
前面十三天寫的是交易的骨架:留言進來、庫存卡住、錢收好、貨出門。這章換一個視角——站在直播現場的人,看到的是什麼。講「後台」之前先劇透結論:這個系統裡沒有一個叫...
權限是我自己認證當年沒做好的部分之一:改了三次,每次都花了真實的時間,每次都只對了一半。有趣的是,把三次改版排開來看,它剛好走完了權限系統的經典演化路徑——所以...
超賣會炸、金流會叫,折扣算錯不會有任何聲音——客人多付了 13 元不會知道,少收了 13 元你也不會知道,直到對帳那天一筆一筆挖。這章講優惠:規則怎麼收納、聰明...
昨天說最優惠演算法被主播砍掉了。砍掉之前,它值得一次誠實的複雜度鑑定——答案分三層,而且最深的一層跟複雜度無關。 岔題,但值得:它到底是不是 NP-hard?...
「通知系統」四個字在教科書裡的長相:一套 notification service、一組 message queue、模板引擎、多渠道 SDK、退避重試框架。這...
先把攻擊模型講清楚。這個系統裡,留言喊單當場佔庫存、付款卻在檔期尾聲——中間隔著幾天的信任。惡意的玩法於是很簡單:喊單、佔住、不付。庫存被白佔最長一整週(檔期長...
Day 20|開賣瞬間(上):尖峰的形狀,與兩種命運 交易和營運的故事都寫完了,接下來幾章講的是貫穿全系統的事:尖峰、維運、對帳。先從所有直播電商的原點講起——...