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

先有單,才有帳號

一般電商的順序是:註冊 → 登入 → 下單。直播代購把它整個倒過來:下單的當下,對方可能什麼都不是——不是會員、沒裝 app、沒登入過。你只知道 FB 說有個 user id 留了 2601+1。

當年的解法,現在回看就是教科書的分層:identity 與 account 是兩回事。

• identity(身分)是事實:fb user、ig user、自建 user——平台說「這串 id 留了言」,這件事不需要任何人註冊就成立。FSM batch 命中 key 的當下,fb user 實體就地建立,單直接掛上去。
• account(帳號)是聚合:客人哪天登入了 app,account 才出現;它不擁有訂單,它認領訂單——把名下綁定的 identity 的單收進同一個視野。

這個分層的關鍵回報:訂單從頭到尾不用搬家。綁定、解綁、多綁一個身分,都只動關聯,不動單——所有跟錢和庫存有關的東西,永遠釘在它誕生時的事實上。

每個欄位都是 id:當年的資料模型

購物車那張表當年是這樣長的:

• cart item 一張表,用 content type + object id(泛型外鍵)標記來源。直播訊息來的單、平台上自己加的單,同一張表、同一套數量調整與結帳邏輯,只有「從哪來」不同。全景提過的兩種購物車,資料模型的答案是:一張表,來源多型。
• 訊息下單另有一張關聯表 fbmsgtocartitem:(fb_user_id, fb_msg_id, cart_item_id, bidding_key_id)——每個欄位都是 id。這代表每筆單都能溯源:哪個人、哪則留言、哪場開賣。客訴「我明明留 +2 怎麼變 +1」,順著 msg id 還原現場;主播重喊清場,順著 bidding key id 一刀切乾淨。
• 眼尖的人會發現 fb_user_id 其實查 fb_msg 就有——放進關聯表是刻意違反 3NF:msg 表太大,而全系統最熱的查詢(LWW 覆蓋要找「此人此 key 的單」)不能穿過它。這是一次教科書等級的安全反正規化,因為拷貝的是不可變的欄位——訊息的作者永遠不會變,這份拷貝永遠不會歪。正規化的實戰判準就藏在這:拷貝不可變的欄位,風險趨近零;拷貝會變的欄位,等於簽下終身同步的合約。

反思

系統裡沒有「人」,只有身分

這章最深的一課,是承認**「人」不是一個 id**。設計者最自然的傲慢,是假設一人一帳號、帳號即本人——然後現實給你看:用家人帳號結帳的客人、一人三個 FB 的客人、永遠不註冊但月月下單的客人。當年的模型能撐住,是因為它從第一天就沒有假裝認識「人」:它只記錄「哪個身分做了什麼」,把「這些身分是不是同一個人」留給綁定去表達,而且允許答案隨時追加。謙遜的資料模型,比聰明的資料模型活得久。

不過,「把身分綁到帳號」這件事,還有一堵 FB 親手砌的牆擋在中間。明天講我們怎麼跟這堵牆共處。

本文改寫自我的部落格系列《Re:從零開始做直播代購電商平台》,本篇完整版:https://blog.aidan.tw/blog/rezero-identity/