BASE Model

在單機系統中，做到強一致性相對容易：
當 transaction commit 時，系統能確保「要嘛全部成功，要嘛全部失敗」，不會出現一半成功、一半失敗的狀況。

然而，在分散式架構下，網路延遲與節點故障是常態，要維持同樣的強一致性就變得極為困難。
為此，eBay 架構師 Dan Pritchett 在論文中提出了 BASE Model，作為理解分散式特性與系統取捨的重要設計指導及討論框架。

• Base: An Acid Alternative

有三個重點：

1. 基本可用 (Basically Available)
2. 軟狀態 (Soft State)
3. 最終一致性 (Eventual Consistency)

以前面註冊流程為例子，來做說明：

1. 基本可用：雖然點數服務故障了，但系統至少建帳號成功了還能用，服務稍候復原可繼續，不影響流程推進。
2. 軟狀態：所有步驟不會一起同步完成，系統有暫時性的狀態，像是失敗、未執行，這樣不完整的中間狀態要「可被接受」。
3. 最終一致性：軟狀態不要求所有步驟一起完成，但流程結束時，每一個步驟都要到達「預期的」狀態。像最後送點數成功、信寄出了。

藉由這三個重點做為思考基礎，繼續往下討論。

BASE Model 原本多用於分散式資料儲存與複寫的一致性思考，強調在網路不可靠、節點常失效的情境下，如何兼顧可用性與最終一致性。但當我們把它套用在分散式流程編排時，要意識到差異：資料同步著重於「副本一致」，而流程則是「跨服務動作的推進與補償」。BASE 可以提供一個設計指導的框架，但我們還需要額外的機制（如狀態機、補償、重試）來真正落實分散式流程的可靠性。

State Machine 狀態機

第二個概念是狀態機，所有狀態及轉換行為都是先定義好的，照定義切換狀態、以及可執行的行為。

那上圖看到的是一個極簡狀態機的例子，on, off 是狀態，會在 press button 這個行為中進行變換。

你以為沒有狀態機，其實它始終在推動一切

在系統中，不論我們是用 排程 (job scheduler) 來安排任務，還是用 事件驅動 (event-driven) 的方式去觸發下一步，其實都牽涉到「狀態的轉換」。
即便開發者沒有明確設計出一個 狀態機，這些流程背後仍然隱含著狀態的存在：

• 排程：一個任務等待被執行、正在執行、執行完成 → 這些都是狀態。
• 事件驅動：事件發生前、事件觸發中、事件處理後 → 也是一種狀態轉移。
• 收貨流程：建立 → 貨到 → 收貨 → 驗收 → 上架 → 入庫可用。
• 製造工單：排程 → 下發 → 開工 → 待檢 → 完工。
• 訂單流程：已建立 → 已付款 → 已打包 → 已出貨 → 已送達 → 已完成。

可怕的是，我們用排程或事件驅動，可能每一個業務流程都自行設計了一套規則，造成狀態轉換邏輯缺乏統一規範，還分散在不同程式碼與服務裡，導致流程難以追蹤、除錯與維護。

因此，只要流程像是需要「等待」「觸發」「完成」「失敗」「重試」這類情境，就等於自然形成了一個狀態機。差別只在於：

• 顯性設計：開發者畫出狀態圖、定義清楚狀態與轉移規則。
• 隱性存在：程式碼分散在事件處理、回呼、排程器的邏輯中，但仍然遵循狀態轉換的規律。

打個比方這張是 Activity 的狀態移轉圖，它的狀態，包含 started, completed, failed, timeout, cancel。可以看到狀態移轉圖中，實際的狀態處理非常繁瑣，每加一個狀態或行為進去就要考慮是否互相影響。

使用 Temporal，我們就不需要再自己手動撰寫這些複雜的狀態處理邏輯。它已經將 狀態轉換、重試機制、逾時、取消、補償 等複雜度收斂在框架裡，開發者只需要專注於描述「業務要怎麼走」的程式，就能用一種很親民、直覺的方式寫出 能自動推進流程的程式。

結語

本篇未涉入具體實作，而是先建立分散式流程的基本定義與思維框架：

• BASE Model 提供了共同的討論語言，幫助團隊對齊重點與取捨，聚焦決策方向。
• 狀態機 則把零散的業務流程抽象為統一的狀態轉換規則，降低上手與變更成本，並加強治理與風險管控。

理解這兩個基礎觀念，能幫助我們看清流程背後的本質與限制。
下一篇將進一步延伸到 狀態管理 與 流程推進 的觀念，探討如何把抽象模型真正落實到可操作的架構設計中。

不誇張的說，學習流程引擎的過程中，我最開心的是對於 BASE Model, Eventual Consistency, State Machine 這幾個核心抽象觀念多了一點認知。