🌐 This page hasn't been translated yet — showing the original Chinese. Translated posts

#live-commerce

重來也不換(核心) FSM・查詢即驗證 事實 append+讀時派生 批次淤而不倒 3NF・庫存雙欄位 per-provider 金流事實表 五個 boring 元件・一台 VM 排序不排期・merge 即上線 轉檔即驗證・泛型外鍵 重來要補(保護) 四個黃金訊號+batch lag 量表 事故的語言:severity・runbook 毒藥訊息的 dead-letter 第一天就上 Cloudflare invariant query 排程(自我對帳) deleted_at・sweep 前反查 負載測試・另外半張 checklist ——全是「保護」,沒有一項是「功能」 核心是對的,欠的全是保護 這也解釋了我後來為什麼走向 SRE

Re:如果真的重來

· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #21

這個系列從一則留言的旅程開始,寫了二十章。終章不新增任何架構,只做四件事:交代結局、講完最後一個月、把三個寫到中段才浮現的體悟收起來,然後回答書名的問題——如果真的重來,我會改什麼。 19 講過那一天…

#war-story#live-commerce#retrospective

站 1:單機 + tenant_id 每張表帶 tenant_id・複合索引打頭 多數 SaaS 的終點站 往下一站的觸發:連線數、資料量、 噪音鄰居——不是「感覺該分散了」 站 2:讀寫分離 replica 吃報表・商城讀流量 寫入仍單點,這站買的是時間 觸發:讀流量壓過寫、報表打擾交易 站 3:Pool + Silo 混合 小商家共居 pool shard・大主播獨立 DB 噪音鄰居的 DB 層解法=企業版分層 per-tenant 備份還原=silo 殺手優點 升艙搬家:單商家停機匯出匯入, 只影響他自己,約在深夜搬 站 4:真分片 Citus 類 shard by tenant_id / NewSQL pool 本身要水平擴的那天才需要 誠實地說: 多數直播代購 SaaS 到不了這站 每一站都有觸發條件——沒被觸發,就留在原站;演進是回應,不是興趣

平行世界:如果變成 SaaS

· tech · 約 11 分鐘 · 📚 Re:從零開始做直播代購電商平台 #20

先交代一件前面十九章都沒說的事:當年我們每一個人,都是降薪進來的。降薪換的是一個承諾——現在做的直播代購平台只是第一站,真正要造的是一艘 SaaS 大船:把整套系統賣給每一個想做直播代購的商家。 船,…

#war-story#live-commerce#system-design

全盛 七人・每天上線 那一天 CTO:暫停開發 合約重談・可能資遣 一個月後 剩三個人 我・一個前端・CTO 新方向 接外部訂單的採購系統 選標搬出・monolith 降格 背景音:商城還開著,但已經沒有客人

三個人的微服務:暫停開發之後

· tech · 約 8 分鐘 · 📚 Re:從零開始做直播代購電商平台 #19

上一章結尾說,這個團隊的終點比所有人想的都近。這章從那一天講起。 某天,CTO 通知全部工程師:暫停開發。與第三方的合約要重新談;可能會走向資遣;他會去幫大家爭取多一點資源。 政治的細節留給終章,這章…

#war-story#live-commerce#microservices

商城線 我(backend lead) 後端 ×1 前端 ×2 CTO:專職做 PM 商城期間不寫程式 工程輸出=4 個工程師 選標線(獨立) 後端 ×1・前端 ×1 專屬 PM ×1 老實說:我不熟這條線 (初期)外包 1–2 人——單人後端時期的止血帶 全遠端・拆分線=組織線(下一章的伏筆)

六個工程師,跑出二十個人的速度

· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #18

系統的故事,到上一章告一段落;剩下的章節要講的,是做出這個系統的人,和這一切是怎麼結束的。先回答一個最基本的問題:前面十七章的系統——FSM、三層訂單、金流事實表、一台 VM 的帝國——是誰做出來的?…

#war-story#live-commerce#engineering-management

直播現場 助理看直播截圖 貼進 dialog、確認 前端:優化 切正方形・轉 webp 為了體驗與頻寬 後端:保證 一律重編碼+thumbnail 原始 bytes 不落地 GCS 原圖+縮圖 兩檔 轉檔即驗證:解不開的檔,轉檔自己失敗 image_metadata:path・content type・object id DB 存 path(事實);API 回應時解出 URL(派生)——實際供圖走 GCS 掛 CDN 前端的處理是優化,後端的處理是保證

上傳容易,刪除難:圖片與資源的生命週期

· tech · 約 9 分鐘 · 📚 Re:從零開始做直播代購電商平台 #17

這章插一個看起來最不起眼的題目:商品圖。「不就是上傳檔案嗎」——這章會用一半的篇幅講上傳,另一半講一件難得多的事:刪除。上傳只要一個下午就能做完;刪除,是一輩子的事。 先看這條管線的真實使用場景,因為…

#war-story#live-commerce#system-design

一台資料庫的裡面 我們的系統 WAL:先寫日誌,再做別的 留言清洗後先 append 落地 log consumer:消化日誌、建索引 FSM batch 消化留言、建購物車 物化視圖:先算好存起來 賣出數量計數(唯一的物化) view:讀的時候才計算 付款/訂單狀態讀時派生 redo log:可重放的變更史 配貨紀錄:可整段重建 內建排程:vacuum、checkpoint heartbeat 掃表:催付、結算 repair:壞了照事實修回來 每小時重算賣出數量 拆開的代價:資料庫免費送的交易保證,得自己一項項補回來 這章要回答的就是:「一致性」這項,我們是怎麼補的

對帳:我們沒有做,為什麼帳還是對的

· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #16

這章在規劃裡叫「三本帳:庫存帳、訂單帳、金流帳」,本來要寫我們怎麼對帳。動筆前照慣例回去查證當年的實際做法,結果是:我們沒有做對帳。 系統裡沒有對帳排程、結束檔期不核帳、上線後也幾乎沒處理過錯帳。 一…

#war-story#live-commerce#data-consistency

13,000 人在線 一台 VM traefik API+WS API+WS API+WS API+WS Celery:heartbeat 排程的心臟 Celery:抓留言 只有 1 個 worker Celery:async task 10 workers・acks_late Redis RabbitMQ 刻意用盡量少的資源做——這是哲學,不是預算 Cloud SQL 8 core・不自己養 DB

沒有 SRE 的年代:backend lead 的上線日記

· tech · 約 9 分鐘 · 📚 Re:從零開始做直播代購電商平台 #15

上一章講尖峰怎麼打;這一章講打仗的人。當年團隊沒有 SRE 這個職稱——身為 backend lead,infrastructure 的仗自然全落在我身上。這章是那段提心吊膽日子的日記:全部家當一台 …

#war-story#live-commerce#sre

200/s 10–20/s 介紹商品 起標:一秒內 10–20 倍 結標中不定時放優惠 → 一連串浪 一場結標:短則 10 秒,平均 3 分鐘 13,000 人在線;副台同時起標時,最壞疊加 ~250 則/秒

開賣瞬間:主播喊完 key 的那三秒

· tech · 約 8 分鐘 · 📚 Re:從零開始做直播代購電商平台 #14

交易和營運的故事都寫完了,接下來幾章講的是貫穿全系統的事:尖峰、維運、對帳。先從所有直播電商的原點講起——主播喊完 key 的那三秒。這章有真實的數字、最痛的一次事故,和一條從被打爆一路通往「雲端菩薩…

#war-story#live-commerce#scalability

第一次 開網頁跳警示 dialog 按「確認」即解鎖 簽收警告・誤殺成本≈0 第二次 鎖一個月 時效到自動解 第三次 鎖三個月 時效到自動解 第四次 永 ban 僅客服可解 再犯一次,往上爬一級——分級讓誤殺變便宜,讓慣犯自己爬上重罰

風控與黑名單:不是逐客令,是信用體系

· tech · 約 6 分鐘 · 📚 Re:從零開始做直播代購電商平台 #13

先把攻擊模型講清楚。這個系統裡,留言喊單當場佔庫存、付款卻在檔期尾聲——中間隔著幾天的信任。惡意的玩法於是很簡單:喊單、佔住、不付。庫存被白佔最長一整週(檔期長度),真想買的客人搶不到,主播的貨卡在幽…

#war-story#live-commerce#risk-control

訊息嚴重度 → private reply 自動・免費・量大 得標通知+綁定 token 政策牆:一則留言 只能回一次 email 常規・內部通知 async 完成通知走這裡 Google Workspace 現成 缺點:會沉底 電話(客服) 人工・最貴・必達 最後通牒:錢要被清、 人要進黑名單之前 渠道來源:綁電話送免運 簡訊:OTP+最後催繳(一檔期只發一次) 簡訊沒催動的,才輪到電話 渠道成本與訊息嚴重度對齊;而觸達權不是接 API 就有的——它是產品換來的

通知系統:兩個欄位、一支排程,和一通電話

· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #12

「通知系統」四個字在教科書裡的長相:一套 notification service、一組 message queue、模板引擎、多渠道 SDK、退避重試框架。這章要講的版本是:兩個欄位、一支排程掃描、…

#war-story#live-commerce#notification

需要券:一張券 = 三個參數的組合 效果 滿額折抵 滿額免運 門檻 滿額多少才生效 + 商品白名單(算進額度的) 範疇 特定檔期/多個檔期 全檔期合算 例:「滿 3000 折 300・限檔期 A・限指定商品」 不需要券:多件優惠 買多少送多少 一個商品可以掛多種 套用順序的故事在下一節 實驗層:Django admin 各種買 A 送 B 的花式組合 實驗性緊急套用 站穩了,才升級成正式規則

優惠與金額:折扣算錯,比超賣還難查

· tech · 約 12 分鐘 · 📚 Re:從零開始做直播代購電商平台 #11

超賣會炸、金流會叫,折扣算錯不會有任何聲音——客人多付了 13 元不會知道,少收了 13 元你也不會知道,直到對帳那天一筆一筆挖。這章講優惠:規則怎麼收納、聰明演算法怎麼輸給主播的一句話、以及讓分攤永…

#war-story#live-commerce#pricing

第一幕 Django group + permission model 級 CRUD 機器的粒度,沒語意 第二幕(+一週) 把 permission 塞進 JWT 錯的粒度被固化 改權限=等重登 第三幕 轉 role-based 語意終於對了 但正交維度一出現 role 數量開始暴增 落點 可疊加的 能力 role cost monitor 乘法變加法 每一步都是局部合理的:用內建的(省時間)→ 塞 JWT(跟無狀態一致)→ 換 role(要語意) 錯不在任何一步,在沒有先問:這個系統的權限,天然的單位是什麼?

權限:誰能按哪顆按鈕——我們改了三次

· tech · 約 11 分鐘 · 📚 Re:從零開始做直播代購電商平台 #10

權限是我自己認證當年沒做好的部分之一:改了三次,每次都花了真實的時間,每次都只對了一半。有趣的是,把三次改版排開來看,它剛好走完了權限系統的經典演化路徑——所以這章與其說是懺悔,不如說是幫後人把路標插…

#war-story#live-commerce#authorization

主播 只看,不操作 留言流 (帶黑名單標籤) 販賣數量 下單的人 觀看人數 (FB API) 用數據抓節奏 直播助理 直播的操作台 商品資訊填入 (事前填/臨時開) 起標・結標 重新起標 追加庫存 替主播動手 營運 另外的獨立頁面 結束檔期 運費設定 入庫單 配貨 管檔期的節奏 客服 處理例外 調整購物車 清除購物車 多重綁定 接住殘量 工程師 Django admin 安全操作台 Celery task 花式需求 (半成品試驗場) 不確定的先住這 底下是同一套事實與 API——同一份資料,五扇不同的窗

主播與營運後台:沒有一個叫「後台」的東西

· tech · 約 5 分鐘 · 📚 Re:從零開始做直播代購電商平台 #9

前八章寫的是交易的骨架:留言進來、庫存卡住、錢收好、貨出門。這章換一個視角——站在直播現場的人,看到的是什麼。講「後台」之前先劇透結論:這個系統裡沒有一個叫「後台」的東西,有的是一組角色介面,每個人打…

#war-story#live-commerce#internal-tools

銷售庫存(承諾) 上限・賣出計數——下單瞬間守超賣 活在毫秒級的交易裡 實體庫存(現實) 入庫單 append——營運登記實際到貨 活在天級的物流節奏裡 兩本帳天生會歪:談好 100 件,到貨 80 件 配貨系統 實際庫存 → 分給訂單;怎麼分,營運決定 配貨紀錄表 append——庫存變動可用全部事件重建 order「全部」配齊 → 產生出貨單(items 一起出,不拆件) 7-11 超商取貨 API 介接・客人網頁選店號 宅配(自配貨運) 人工匯出 CSV 交給貨運

出貨前處理:賣的是承諾,出的是現實

· tech · 約 7 分鐘 · 📚 Re:從零開始做直播代購電商平台 #8

錢收完了,該出貨了。這章是系統與實體世界的交界——留言、庫存、金流都活在資料庫裡,但貨是真的紙箱、真的倉庫、真的宅配司機。也因此,這是全系列「系統邊界」劃得最有意識的一章:哪些歸系統管、哪些交給人,當…

#war-story#live-commerce#fulfillment

orders payment 狀態不儲存,讀取時聚合:已付 = SUM(入帳事實) ≥ 應付 銀行 A・智慧轉帳 事實表 銀行 A・信用卡 事實表 銀行 B・付款 事實表 現金入帳 營運標記 150,000 單筆上限 3 萬 = 五筆事實 webhook(即時) 銀行主動通知 polling(兜底) 排程主動查單 雙通道寫進同一組事實表——事實冪等,重疊無害,互為備援

第三方金流:教科書的三個坑,與一個沒有坑的地形

· tech · 約 6 分鐘 · 📚 Re:從零開始做直播代購電商平台 #7

上一章把單聚合成了三層,現在要收錢了。金流是這個系統第一次把「正確」交到別人手上——付款發生在銀行那邊,你只能透過不可靠的網路得知結果。教科書會警告你三個坑:通知會重複、會亂序、會根本不來。這章要講的…

#war-story#live-commerce#payment

佔庫存購物車(直播) 可橫跨多個檔期/實況主 不佔庫存購物車(商城) 同一張 cart item 表,來源多型 合併結帳 orders payment —— 付錢的單位 跨檔期一次付清・聚合第三方付款事實(下一章) order(檔期 A) 履約單位・檔期優惠記這層 order(檔期 B) 按檔期切 order(檔期 C) 跟著各自的出貨節奏 order item —— 會計單位:成交時定格金額,發票/退款以它為準

購物車到訂單:被主播拔掉的狀態機

· tech · 約 8 分鐘 · 📚 Re:從零開始做直播代購電商平台 #6

交易主線的最後一站:單怎麼從購物車走到訂單。留言進了購物車、身分掛好了單、庫存卡住了不變量——這章把它們聚合成一筆可以付錢、可以出貨、可以開發票的東西。標題不是比喻:這個系統裡真的有一台狀態機,被主播…

#war-story#live-commerce#system-design

product 價格、商品資訊 直播中會一直變 1:1 庫存表(熱資料,獨立一張) 庫存上限 —— 主播追加貨=只調這裡 購物車數量(預留) 訂單數量(成交) 付款:購物車 → 訂單,同一筆交易內轉移 不變量:購物車 + 訂單 ≤ 上限(可賣=導出值,不存「剩餘」) FSM batch 下單・LWW 改單 客人 自行調整數量 客服 清除・調整購物車 助理/營運 追加貨・結束檔期 寫入者有四方——但每小時會從 cart/order items 全量重算兩個計數(派生值的自我修復)

庫存:不能超賣,是這個系統唯一的鐵律

· tech · 約 8 分鐘 · 📚 Re:從零開始做直播代購電商平台 #5

留言解析完、身分掛好單,主線走到心臟:庫存。這個系統的功能清單可以慢慢長,但只有一條規則從第一天就是鐵律——不能超賣。賣掉不存在的貨,是要一個一個跟客人道歉退款的。這章講當年怎麼守這條不變量、它被什麼…

#war-story#live-commerce#inventory

identity:身分是事實 fb user(PSID) 留言當下就地建立 ig user 自建 user account:帳號是聚合 account 登入後才出現 認領 identity 的單,1:N 綁定(可多重) cart item(佔庫存) 掛在 fb user 上,不是 account 上 fbmsgtocartitem msg id・bidding key id 聚合視圖:認領即收編,訂單不用搬家

身分與帳號:留言的那個人,到底是誰

· tech · 約 9 分鐘 · 📚 Re:從零開始做直播代購電商平台 #4

上一章的 FSM 解出了「誰買了什麼」——但那個「誰」,其實只是 FB 給的一串數字。他可能從來沒註冊過我們的平台,可能明天才會登入,可能永遠不會。而庫存現在就要卡給他。這章講全景裡我說「全系列最容易…

#war-story#live-commerce#identity

FB(100)・輪詢 IG(10)・webhook 自建(1)・直推 取回:各源各自的接法 FB 輪詢自適應:忙續抓、閒放慢 殊途同歸進同一張表 清洗 → 落地 統一 message 格式 append 去重鍵:source+message id batch 200・FSM 解析 → 查 bidding key 扣賣出數量+建立身分 raw 有落地・FB 可整場重抓——但從沒被動用 處理失敗 → 直接略過,沒有補救路徑 一切為了主播眼中最新鮮的庫存狀態;代價:尖峰 lag 可達幾分鐘、掉單無聲

留言即下單:把聊天室變成下單通道

· tech · 約 13 分鐘 · 📚 Re:從零開始做直播代購電商平台 #3

全景和起手式鋪完,進主線第一戰:一則留言,怎麼變成一筆單。這章講「接進來」和「解析」兩段,佔庫存的攻防留給下一章。主角是把聊天室變成收銀機的那台有限狀態機——我們會直接讀它的程式碼。 留言來自三個源:…

#war-story#live-commerce#fsm

留言進來 FB / IG / 自建 統一留言事件 每源一個 adapter 解析 key+n 同人重複取最後一筆 身分 identity 沒帳號也要能掛單 佔庫存購物車 庫存 −n・不能超賣 結帳 兩種購物車合併 第三方金流 webhook・冪等 出貨前處理 合併出貨・交物流 逾期未付 → 釋放庫存 每一站都是系列的一章:留言接入、身分、庫存、購物車、金流、出貨前處理

全景:留言下單的一筆訂單,會經過哪些系統

· tech · 約 6 分鐘 · 📚 Re:從零開始做直播代購電商平台 #1

這是一個新系列,也是這個部落格第一個戰爭故事。我在前公司實際做過一個直播代購電商平台——使用者看直播、在留言區打字下單,後面接著庫存、金流、物流一整條鏈。這系列不是回憶錄:我想帶著現在的功力(DDIA…

#war-story#live-commerce#system-design