經典架構拆解 · 05 — Airbnb 搜尋排名與金流分帳
Airbnb 是個雙邊市場（marketplace）：一邊是房東、一邊是房客，中間夾著搜尋排名、信任評分、跨國金流。這三件事對架構師來說，每一件單獨拿出來都夠寫一套系統，湊在一起就更不簡單了。
這是 經典工程架構拆解 系列的第 5 篇，上一篇看了 Slack 的 WebSocket 與已讀同步。
為什麼值得拆解
大部分電商平台的搜尋就是「關鍵字比對 + 排序」。Airbnb 不一樣，它得同時考慮每個房客的偏好、每間房的動態定價、當前空房日期、平台政策，說穿了就是一套即時跑的個人化推薦系統。
金流更難：一筆訂單可能涉及房客的信用卡幣別、房東的提現幣別、平台抽成、當地稅務代繳、清潔費、押金。架構師要學的是：怎麼把「訂單」和「分帳」分開設計。
商業規模與壓力
根據 Airbnb 2023 年報與公開技術演講：
- 全球掛牌房源超過 760 萬間，分佈在 10 萬個城市（Airbnb 2023 10-K 年報）1。
- 2023 年全年訂房夜與體驗數超過 4.48 億晚，代表平均每秒約 14 筆預訂（同上年報）1。
- 支援超過 40 種結算幣別，信用卡收單橫跨多個地區的 PSP（payment service provider）（Airbnb Engineering Blog 多篇）2。
壓力主要在兩邊。搜尋這邊，延遲要壓在 幾百毫秒內，但每次搜尋又得對數千個候選房源跑機器學習排名；金流那邊，資料一筆都不能掉，還要能事後審計回溯（audit trail）。
架構演進簡史
| 階段 | 年份（約） | 關鍵變化 |
|---|---|---|
| Monolithic Rails + MySQL | 2008–2014 | 整個 Airbnb.com 跑在一套 Rails monolith 上 |
| SOA（Service Oriented Architecture） | 2014–2018 | 拆成數百個服務，內部稱為 “Great Migration”（Airbnb Engineering Blog 公開系列）3 |
| Search ML 導入 GBDT → Deep Learning | 2015–2019 | 搜尋排名從手寫權重改用 Gradient Boosted Decision Tree，後改 Deep Learning（Airbnb KDD 2018 論文）4 |
| Payment Ledger 獨立服務 | 2015 以後 | 把所有金流狀態變動抽成 event-sourced ledger（Airbnb Engineering Blog “Avoiding Double Payments”）5 |
| Data Mesh 與 Dataportal | 2019 以後 | 資料治理平台 Dataportal，讓搜尋與 ML 特徵共享 |
核心技術決策
| 決策 | 為何 | 替代方案 |
|---|---|---|
| 搜尋排名用 learning-to-rank | 規則太多，手寫權重無法維護 | 純關鍵字比對（體驗差） |
| Payment Ledger 採 event sourcing | 金流要能回溯、對帳、合規稽核 | 直接改餘額（無法追蹤歷史） |
| 兩階段提交（2PC）處理跨服務付款 | 訂單成立與扣款必須一致 5 | 最終一致（會有雙重扣款或未扣款風險） |
| 搜尋走專屬 ML 服務 | 排名計算重，與交易型資料庫分流 | 把 ML 放在主庫查詢（DB 會被打爆） |
| 多幣別在 ledger 層處理 | 避免每個服務自己轉匯、誤差累積 | 每個服務各自轉（最後對不起來） |
金流的關鍵設計： Airbnb Engineering Blog 那篇 “Avoiding Double Payments in a Distributed Payments System” 講得很清楚，他們是用冪等 key + 狀態機 + retry這組合來防重複扣款。思路其實跟 Stripe 的冪等性設計很像，只是搬到雙邊市場來用5。
如果用 GCP 重新蓋
| Airbnb 元件 | GCP 對應 |
|---|---|
| 搜尋排名 ML 模型訓練 | Vertex AI Training，特徵存 BigQuery + Feature Store |
| 線上推論 | Vertex AI Prediction 或 GKE + TensorFlow Serving |
| 候選房源索引 | Elasticsearch on GKE 或 Vertex AI Search |
| Payment Ledger | Cloud Spanner（跨 region 強一致 + 交易） |
| 訂單資料 | Spanner 或 Cloud SQL（依跨 region 需求） |
| 分析與對帳 | BigQuery + Dataflow 做 CDC 抽 ledger |
| 信任與風控 | Vertex AI 訓練詐欺偵測模型 + reCAPTCHA Enterprise |
| PII 保護 | Cloud DLP 掃信用卡號、身分證；CMEK（客戶自管金鑰）加密 |
| 多區影像與房源照片 | Cloud Storage + Cloud CDN + Imagen API 做自動描述 |
PCA 考點映射
- 交易型 vs 分析型資料庫：Payment Ledger 需要強一致、跨 region 交易 → Spanner。Dashboard 分析 → BigQuery。PCA 常考「不要把 OLTP 跟 OLAP 放同一個資料庫」。
- ML 服務選型：Vertex AI 的三個面向（Training、Prediction、Feature Store）各自解決不同問題，考試會給你一個搜尋排名場景，要你選「自建 TensorFlow on GKE」還是 managed Vertex AI。答案通常是 Vertex AI（除非有特殊客製需求）。
- PII 與合規：金流、房客身分證都是 PII（personally identifiable information）。考試會問「怎麼讓分析團隊能用資料但看不到敏感欄位」→ Cloud DLP 的 de-identification + BigQuery column-level security。
常見誤解
- 「搜尋排名就是 Elasticsearch。」 Elasticsearch 只負責「候選召回（candidate retrieval）」，真正決定順序的是後面接的 ML ranking 層。Airbnb KDD 2018 論文明確區分這兩層4。
- 「多幣別處理就是每次下單時呼叫匯率 API。」 正確做法是在 ledger 記下「當時匯率 + 原始幣別 + 結算幣別」三個欄位，避免事後匯率變動造成對帳困難。
- 「event sourcing 就是把日誌寫到 Kafka。」 Event sourcing 是「狀態 = 所有事件的摺疊（fold）」這個設計哲學，Kafka 只是一種實作載體。
來源與延伸閱讀
下一篇（本系列最終篇）：經典架構拆解 · 06 — Discord 百萬人頻道與 NoSQL 選型，看另一種極端的即時通訊架構怎麼從 Cassandra 換到 ScyllaDB。
需要對照官方 case study？到 PCA 案例資料庫。
🎯 換你練習
想動手設計類似系統？到 架構師設計工作坊 用這套思考步驟走一遍。
Footnotes
-
Airbnb 2023 Annual Report (10-K) — 官方財報中揭露的房源數、訂房晚數、營收規模。 ↩ ↩2
-
Airbnb Engineering Blog — 官方工程部落格，搜尋、金流、ML 多篇公開文章來源。 ↩
-
Our Journey Towards a Production-Ready Service-Oriented Architecture — Airbnb Engineering — Monolith 拆 SOA「Great Migration」的工程記事。 ↩
-
Real-time Personalization using Embeddings for Search Ranking at Airbnb — KDD 2018 論文 — 搜尋 embedding 與排名架構的正式論文。 ↩ ↩2
-
Avoiding Double Payments in a Distributed Payments System — Airbnb Engineering — 官方介紹冪等性與狀態機如何避免重複扣款。 ↩ ↩2 ↩3