接續上篇 CAP Theorem 的介紹

我們以 訂房系統 為例

訂房系統

假設我們設計了一個類似 Agoda, Booking.com 等的 訂房系統, 使用者能夠透過我們的系統查看 / 訂房 (先不考慮登錄房型)

使用者下訂單的流程如下

1. 打開訂房網站頁面
2. 選擇入住日期與人數
3. 找到喜歡的房型
4. 進入訂房頁面
5. 填寫付款資訊
6. 付款並下訂

我們將著重在第 6 步驟: 付款並下訂
此步驟在系統會包含以下 3 步

1. Internal API 請求 Inventory Service 檢查房間是否足夠並更新庫存
2. 庫存足夠則 Internal API 請求 Payment Service 發送請求給 PSP (Payment Service Provider), 並紀錄付款狀態 (後續流程如 Day 12 介紹)
3. 付款後 Internal API 請求 Booking Service 紀錄使用者訂房資訊

強一致性

從上圖可以看到, 假設我們將使用者 "付款並下訂" 視為一個 transaction, 並且每個 Service 的操作也都是一個 transaction, 總共就有 4 個 transaction
等到 3 個 Service 都同步完各自的資料才給使用者最終結果

由於跨節點的同步需要很久, 效能就會比較差

最終一致性

就像前篇提到的, 如果我們改用 Saga Pattern, 就可以 "不用即時更新並同步跨節點的資料", 讓使用者體驗更好
相較於 強一致性 讓使用者等待很久後拿到結果, 最終一致性可以先回傳已下訂的資訊, 再引導使用者去類似 訂單查詢的頁面即可

Reference

• System Design Interview - An Insider's Guide: Volume 2, CH.7