決定用事件重劃服務邊界之後：一則事件帶多少資訊、流程誰指揮、訊息如何可靠地離開交易。

訊息系統的骨幹已由三篇講清楚：訊息佇列基礎篇定義 Queue 與 Log、以及 at-least-once 是預設；Kafka 架構篇把一則紀錄定址成 topic + partition + offset；串流處理篇在那條可重放日誌上做視窗與水位。本篇不再重講那些定義。這裡要答的是另一個問題：服務之間為什麼改用事件說話，以及說出去之後怎樣才算可靠。

同步 RPC 把「我改完自己的狀態」和「你也改完你的狀態」綁在同一次呼叫。呼叫者承擔對方的延遲、重試與容量；兩邊的資料庫卻從來不在同一筆交易裡。事件驅動把這條線拆開：一個服務先把自己的事實寫下來，再以事件通知其他人。耦合從「你必須現在回應我」變成「你何時跟上這則事實」。換來的是最終一致、可獨立擴充的消費者，以及一條新的失敗面——訊息可能沒離開交易、可能重複抵達、可能帶著舊 Schema 撞上新消費者。

與 分散式交易手冊 的界線必須畫清。那篇負責 2PC / TCC / Saga 的理論與補償語義——什麼時候該 Try、什麼時候補償、協調者掛了怎麼辦。本篇假設你已經決定改走事件，只談這之後的工程：訊息如何跟本地交易綁在一起離開、重複與亂序抵達時 handler 怎麼不寫壞下游。補償步驟的設計不在這裡重述。

Notification、Event-Carried State Transfer、Event Sourcing：耦合、回查與重建，三者不可同時最好。

「訂單已付款」可以是三則完全不同形狀的事件。差別不在主題名稱，在消費者要不要再回頭問發布者，以及這則事件能不能獨立重現當時的世界。

三個指標一起看

沒有「事件就該帶全量」或「事件就該只帶 ID」的教條。看消費者能不能忍受回查、以及你是否真的要把事件當帳本。

Notification 的隱藏耦合常被低估：消費者回查時，發布者可能已經走到下一狀態。「已付款」通知抵達時訂單已退款，回查看到的是 refunded。你以為在訂閱一個事實，其實在輪詢一個會變的列。Carried State 把「付款那一瞬」凍在 payload 裡，換來的是契約要一起演進。Event Sourcing 再往前一步：連「現況列」都不當真相，任何讀模型都是可丟可重建的投影。

把一則信封攤開來看

上面三種風格的差別，落到程式裡就是「信封裡放哪幾個欄位」。下面這台拆解器把一則真的 OrderPaid 攤成逐欄台帳：每一欄屬於哪一類、佔幾個 byte、少了它下游會怎樣。信封與舊契約都可以直接編輯，最下面那張卡會即時算出這次欄位改動在四種 Registry 相容性模式下會不會被拒登——相容性模式本身的定義留給本篇談 Schema 演進的那一節，這裡先看「改了欄位會發生什麼」。

三個值得停下來比對的地方：(1) 預設信封 309 bytes，但業務事實只占 31.4%——68.6% 是信封稅，這是 Carried State 的真實重量。(2) 把冪等鍵換成 aggregateId + occurredAt，四種孿生事件的答對數從 4/4 掉到 1/4；換成 payload 內容雜湊是 3/4，而且錯的那一種是「誤擋」——它會把合法的第二筆同金額付款當成重投丟掉。(3) 把台帳上七個新欄位全部點成「選填」，相容性從「只有 FORWARD 成立」變成 FULL，拒登的 Registry 模式從 2 個降到 0 個。bytes 由規範化序列化算出，與你在框裡怎麼縮排無關；「選填」在本模型裡同時代表 optional 與「有預設值」，兩者對 BACKWARD 的效果相同。

實務上大多數服務間整合走 Carried State：帶消費者做完這一步所需的欄位，不多帶「以後也許用得到」的整張聚合。要稽核或時間旅行再對同一條 log 做 Event Sourcing 投影，而不是要求每個消費者都重放全歷史。Notification 留給「欄位極大、回查很便宜、且消費者本來就要打 API」的內部後台。

沒有中央指揮時流程長在訂閱關係上；有指揮時流程長在管理員的狀態機上。

一筆訂單要經過付款、扣庫存、開出貨單。用事件串起來有兩種拓撲。補償「失敗了怎麼退」的語義在分散式交易那篇；這裡只問：下一步由誰決定、出了差錯你在哪裡看見整條鏈。

sequenceDiagram
    participant P as 付款服務
    participant T as 事件主題
    participant I as 庫存服務
    participant S as 出貨服務
    P->>T: OrderPaid
    T->>I: 訂閱送達
    I->>T: StockReserved
    T->>S: 訂閱送達
    Note over I,S: 下一步由訂閱者自己決定
  

Choreography：沒有人握著整條鏈——每個服務只看見自己訂閱的那則事件，下一步長在訂閱關係上，中央的主題只負責轉送、不做決定。

sequenceDiagram
    participant M as 流程管理員
    participant I as 庫存服務
    participant S as 出貨服務
    M->>I: ReserveStock
    I-->>M: StockReserved
    M->>S: CreateShipment
    Note over M: 流程狀態集中在這裡
  

Orchestration：三條訊息都從管理員發出或回到管理員，它既是發起者也是回覆的收件人，所以「現在卡在哪一步」只要查它一處。

三個常被混為一談的成本

可觀測性。 Choreography 的「這筆訂單為什麼卡在出貨前」要沿主題把相關事件撈齊，或另做關聯追蹤。沒有單一行程表。Orchestration 的管理員列就是行程表：卡在哪一步、等哪個回覆、超時幾次，打開就看見。代價是管理員成為查詢熱點，也成為部署時你必須保住的狀態。

變更成本。 在既有鏈上插入「風控檢查」，Choreography 往往要改某個服務的訂閱與發出——你得找到「誰該在付款之後、扣庫存之前」插一腳，訂閱關係變成隱式工作流。Orchestration 改狀態機：舊參與者繼續聽自己的命令即可。反過來，加一個完全旁路的讀模型（搜尋索引、稽核），Choreography 只是多一個訂閱者，Orchestration 卻可能要管理員多發一次通知，否則新服務看不到命令通道裡的流量。

失敗處理。 這裡不重講補償理論。只標工程後果：Choreography 的失敗是「某服務沒發出下一則事件」，超時與補救散落在各消費者；Orchestration 的失敗是「管理員沒等到某則完成事件」，重試、放棄、轉人工可以寫在同一處。兩者都還是 at-least-once：管理員重發命令、或消費者重放事件，下游都必須把效果做成可重入。那是第 5 節的工作，不是選拓撲就能省略的。

選法可以很具體：流程短、旁路讀者多、步驟很少回頭——Choreography。流程長、要給客服一個「現在卡在哪」的畫面、步驟常改——Orchestration。同一系統可以混用：核心履約走管理員，搜尋與通知走旁路訂閱。

資料庫與訊息代理不是同一筆交易。Outbox 把「要說出去的話」先寫進同一顆資料庫。

服務剛改成事件驅動時，最常見的實作是兩行：先 UPDATE orders SET status='paid' 並 commit，再 producer.send(OrderPaid)。這叫雙寫（Dual Write）。兩個系統各自有自己的提交，中間沒有共同的 commit 點。崩潰、行程被殺、broker 暫時拒收，都會讓兩邊的事實分開。

兩種順序都解不了，因為問題不在順序，在你要求兩個非原子的提交表現得像一個。分散式交易那篇用 2PC 硬把它們焊在一起；本篇走的是另一條：不把 broker 拉進同一筆交易，只保證「本地列」與「打算發出的訊息」同生共死。

Outbox 表長什麼樣子

同一筆本地交易裡寫兩件事：業務列，以及一列 outbox。交易 commit 之後，業務狀態與「有一則話等著說」要嘛一起留下，要嘛一起消失。發佈器是交易外的另一個程序，負責把留下的話送到主題。

最小可用集合。實際還會加 schema_version、headers、以及發佈失敗次數。不要在發佈器裡再回查業務表拼 payload——當時的事實已經在 payload 裡。

分界在 COMMIT：t1–t2 兩筆寫入共用一次提交，t3–t4 的投遞與標記全發生在交易外——所以主題上可能重複，但意圖不會遺失。

誰把 outbox 列變成主題上的紀錄

兩種發佈器，契約相同：只讀 published_at IS NULL 的列，送到 broker，再標已發。

• 輪詢。 背景行程 SELECT … FOR UPDATE SKIP LOCKED 一批、送出、更新 published_at。實作簡單，延遲等於輪詢間隔，資料庫多一條熱查詢。多實例要用鎖或租約，避免同一列被送兩次——即便送了兩次，也只是把 at-least-once 提前暴露，消費端本來就要去重。
• CDC。 訂閱資料庫的變更日誌，outbox 的 INSERT 出現在 WAL 裡就轉成主題紀錄。延遲通常比輪詢低，也不占那條熱查詢。WAL 格式、解碼器、快照與增量切換，留給 CDC 那篇；此處只需記住：CDC 沒有取消 Outbox 這張表，它只是換一種讀取方式。若直接把整張 orders 的 row change 當領域事件，你又回到「CRUD 當事件」的陷阱。

裂縫到底有多寬

上面那張 swimlane 說的是「步驟是什麼」。下面這台模擬器問的是另一個問題：在哪一步斷掉會怎樣。它對每一個故障點各跑一次完整模擬（開交易、提交、崩潰回滾、送出、重啟後補送、消費），再依最終的耐久狀態分類結局，所以你看到的不是一次播放，是整條結局光譜——雙寫的 bug 因此有了「多寬」這個量。

四個值得停下來比對的位置：(1) 預設（先寫庫、broker 接受、天真 handler）——雙寫只有「t2 之後」這一格不一致（裂縫 1/6），窄得剛好能通過測試、卻會在線上咬人；而 Outbox 在「t4 之後」那一格是重複扣量（送出成功、published_at 還沒回填就崩潰，重啟後再送一次，主題上 2 則、qty 掉到 6）。(2) handler 換成去重表：Outbox 那一格變回一致、qty 回到 8，雙寫那一列一個字都沒變——去重表補的是重複，補不了遺失。(3) 順序換成「先發訊息再寫庫」：裂縫變成 2/6，而且失敗的性質從「遺失」變成「幽靈」——兩種順序都解不了，只是裂法不同。(4) broker 改成首次拒收：雙寫的裂縫從 1/6 撐到 5/6，而 Outbox 那一列連重複格都消失了——沒送成功，就沒有東西可以重複。

交付語意已經定義過。這裡只談 handler 如何讓同一則事件做兩次，世界仍只變一次。

訊息佇列基礎篇把 at-least-once 講成預設：broker 在 ACK 前可以再投一次，消費者在處理後、ACK 前崩潰也會再收到。本篇不重定義那三個詞。事件驅動落地時，你要設計的是效果：庫存不該被扣兩次、通知不該寄兩封、讀模型不該把同一筆付款加兩次。

冪等鍵與去重表

每一則離開 Outbox 的事件帶一個穩定 id（outbox 主鍵、或業務側的 orderId + eventType + version）。消費者在同一筆本地交易裡做兩件事：

以及真正的副作用（扣庫存、寫出貨單）。衝突代表「這則我做過了」：這是保護成功，不是業務失敗。不要把去重表做成「先查再做」的兩步——兩步中間崩潰，第二個實例會以為沒做過。必須用唯一鍵把「我要做」宣告成插入本身。

亂序比重複更安靜

同一聚合的兩則事件不必依發生順序抵達：網路重試、多分割區、或 Choreography 上兩個發布者並發，都會讓 AddressChanged(v2) 先於 AddressChanged(v1) 到。去重表只擋「同一 id」，擋不住「舊版本覆寫新版本」。

• 帶單調版本。 寫入時 WHERE version < incoming；擋下的舊事件 ACK 即可，不要當錯誤重試到爆。
• 不要對事實事件做 last-write-wins 卻不記版本。 牆鐘可比歪，LWW 會讓先發生的改寫後來的。
• 真正的因果（必須先付款再開出貨） 用 Orchestration 等完成事件，或在消費者緩衝並檢查前置條件；不要假設主題全域有序。Kafka 只保證單一 partition 內有序——跨聚合、跨主題沒有這份保證，細節回 Kafka 那篇。

生產者與消費者不會同一秒升級。相容性模式決定誰可以先走、誰必須等。

Carried State 把契約變成跨團隊的 API。欄位一改，舊進程與新進程會在同一條主題上共存數小時到數週。Schema Registry 不做序列化，它做的是攔下不相容的新版本，讓這段共存期有規則可守。

本節這張模式表就是前面那台事件信封拆解器裡「相容性判定」那張卡實作的規則：它逐欄比對新舊契約，把每一項改動歸到下表的某一格，再摺疊成「哪個方向成立」。想邊讀邊試的話，回去改那則信封的欄位，看下面四種模式各自的反應。

四種相容性模式

BACKWARD / FORWARD 有時帶 _TRANSITIVE：不只對上一版，對歷史每一版都要成立。多版本長期共存時用它。

一個具體走法。v1 是 { orderId, amount }。v2 加上可選的 currency，預設 TWD：

• 新消費者讀 v1 資料：缺 currency，填預設 → BACKWARD 成立。
• 舊消費者讀 v2 資料：多一個不認識的欄位，若執行期「忽略未知欄位」→ FORWARD 成立。

v3 把 amount 改成 amountCents。這是重新命名，兩個方向都破：舊消費者找不到 amount，新消費者在舊資料裡找不到 amountCents。FULL 會在登錄時拒絕；NONE 會讓一半進程在半夜反序列化失敗。

Notification 風格幾乎不需要 Registry：契約只有 ID。Event Sourcing 相反，歷史每一版都可能在重放時再被讀一次——相容性必須是 transitive 的，舊事件不能因為你今天改了欄位就變成垃圾。Carried State 落在中間：為「現在這條主題上的活躍消費者」守 FULL 或 BACKWARD，通常就夠用。

先答事件帶多少、流程誰指揮、訊息怎麼離開交易。補償理論、broker 內部、視窗運算各有自己的篇。

下一站：把資料庫變更日誌變成事件流，見 CDC。交付語意回訊息佇列基礎；分段與 ISR 回 Kafka；視窗與水位回串流處理；補償語義回分散式交易。