觀察

Spanner 公開數字（引自 Spanner overview / Spanner performance docs）：

代表性客戶：Google 內部所有支付、廣告計費、Play 商店、Search 索引；公開客戶包括 Blockchain.com、Niantic（部分服務）、Sharechat、ZEE5、Wayfair。

關鍵設計：TrueTime API（GPS + 原子鐘）讓跨地區交易能維持 external consistency、不是 eventual。

判讀

Spanner 案例最值得讀的不是「能撐多大」、是「為什麼要這樣設計才能撐」。

1. 線性擴展是 OLTP 的最高設計目標：「2 nodes → 45K reads/sec、4 nodes → 90K reads/sec」這個 linear scaling 在傳統 OLTP（PostgreSQL、MySQL）做不到 — 因為 跨節點交易 需要 coordinator、coordinator 是 bottleneck。Spanner 用 Paxos + TrueTime 把 coordinator 變成「拓樸感知的多 leader」、才達成線性。對應 01.5 transaction boundary 的設計取捨。
2. 強一致 vs 全球部署不是必須二選：CAP 定理常被解讀為「全球部署只能 eventual consistency」、Spanner 顯示「投入專屬硬體（GPS、原子鐘）+ 演算法（TrueTime）可以同時拿到 strong consistency + global distribution」。但這套硬體投資對其他 vendor 不容易複製。對應 01 資料庫模組 的全球 OLTP 選項。
3. 計費粒度 = 容量規劃顆粒：Spanner 早期最小單位是 100 processing units（pu）≈ 1 node、太大讓中小負載難以用。後來推出 100 pu 起跳的 granular sizing、讓容量規劃可以從小開始。對應 9.7 成本邊界與 efficiency 的容量單位選擇。

需要警惕：「10 億 req/sec」是 Google 內部的某個峰值瞬間、是 Spanner 服務 全部使用者加總、不是單一 instance 數字。讀案例時要區分「全球聚合峰值」跟「單一客戶能拿到的最大配額」。

策略

可重用的工程做法：

1. 跨地區一致性需求要在設計初期決定：如果業務必需 strong consistency（金融、ticketing）、選 Spanner 等對等服務；如果 eventual 可接受（社群、推薦）、選 Cassandra / DynamoDB Global Tables 等更便宜的選項。對應 00 服務選型模組 的全球一致性需求識別。
2. 節點數即容量單位、預先規劃 sizing：Spanner 容量 = 節點數 × 單節點 QPS。每年 capacity review 主要在調節點數、不在調 schema。對應 9.6 容量規劃模型。
3. 跨地區 latency 是強一致的代價：external consistency 必須等多區 quorum、跨洲交易延遲可達 100-200ms。延遲敏感型業務不能用跨地區 strong consistency。對應 9.12 SLO 與 Performance Budget 的 latency budget 反推。

跨平台等效：AWS Aurora DSQL（2024 推出、跨地區 strong consistency）、CockroachDB（自管）、TiDB（自管或 cloud）都是對等候選。差異是 TrueTime / 同等同步機制的成熟度。

下一步路由

• 想評估全球一致性需求 → 00 服務選型模組 + 01.5 transaction boundary
• 想規劃 OLTP 容量 → 9.6 容量規劃模型 + 01 資料庫模組
• 想對照其他 OLTP 案例 → 9.C4 DraftKings Aurora
• 想看不需要強一致的全球 KV → 9.C11 Minecraft Earth Cosmos DB
• 想理解 TrueTime ε 與外部一致性實作 → Spanner TrueTime API 深入
• 想對照 Spanner / Aurora DSQL / CockroachDB 不同一致性層 → Spanner 一致性模型對照

引用源

• Spanner: Always-on, virtually unlimited scale database
• Spanner Performance overview
• Using Cloud Spanner to handle high throughput writes
• Get more out of Spanner with granular instance sizing
• Amazon Aurora DSQL for global-scale financial transactions

觀察

Riot Games 遷移到 EKS 的關鍵數字（引自 Riot Games case study）：

服務組合：Amazon EKS（主要）、AWS Local Zones（低延遲就近部署）、AWS Outposts（on-prem edge）、Karpenter（node lifecycle）、Terraform（IaC）。

關鍵架構決策：從 multi-tenant cluster 模型改成 single-tenant per game — 每個遊戲一個獨立 cluster、避免跨遊戲互相影響。

判讀

Riot Games 案例揭露三個多 cluster K8s 容量治理重點。

1. Cluster 隔離是容量規劃的單位：246 個 cluster 看似很多、但 每個 cluster 是獨立容量單位、不互相影響。一個遊戲的擴容不會吃掉另一個遊戲的容量。對應 05 部署平台模組 的 multi-tenant vs single-tenant 取捨。
2. 延遲門檻反推 region 部署：35ms 是競技遊戲（VALORANT、League）的可接受上限、超過會「卡」。從這個門檻反推：玩家所在 region 不能跨洲、需要區域 cluster。對應 9.12 SLO 與 Performance Budget 的 latency budget。Local Zones / Outposts 是這個門檻的工程回應。
3. Karpenter + Terraform = cluster 容量自動化：246 個 cluster 手動管理會崩。Karpenter（node 動態 lifecycle）+ Terraform（IaC）讓 cluster 級操作可重複、可審查。對應 9.9 Performance Improvement Loop 的自動化迴圈。

需要警惕：「年省 1000 萬」是 vs 自管 Mesos、不是 vs 沒上雲。EKS 仍有 vendor cost、只是比自管便宜。讀案例時要看 baseline 是什麼。另外、單一 cluster 的容量上限（pod 數、node 數）仍是工程現實、超過時要做 cluster sharding（這正是 Riot 走 246 個 cluster 的部分原因）。

策略

可重用的工程做法：

1. single-tenant cluster per workload：每個高敏感度工作負載（每個遊戲、每個關鍵服務）一個獨立 cluster、避免 noisy neighbor。對應 05 部署平台模組。
2. 延遲門檻反推 region 部署數量：先訂 latency budget、再算 玩家分布 × region cluster 數量。region 增加會線性增加 ops 成本、要在 latency 跟 cost 之間找平衡。對應 9.7 成本邊界與 efficiency。
3. cluster 級 IaC + 自動化是 multi-cluster 治理前置：Terraform / Pulumi / Crossplane + Karpenter / Cluster Autoscaler 是基本工具。

跨平台等效：GCP GKE Fleet management（multi-cluster）、Azure Fleet Manager、自建 Cluster API + ArgoCD 都可以做 multi-cluster 治理。差異是 vendor 整合度跟政策。

下一步路由

• 想設計 multi-cluster K8s → 05 部署平台模組 + 9.6 容量規劃模型
• 想做延遲門檻反推部署 → 9.12 SLO 與 Performance Budget + 9.C3 Coinbase
• 想對照微服務 vs multi-cluster → 9.C7 Lyft

引用源

• Riot Games Cuts $10M Annual Infrastructure Costs by Migrating to Amazon EKS
• Riot Games on Using AWS to Improve Gaming

觀察

Genesys Cloud 在 DynamoDB 的關鍵數字（引自 Genesys DynamoDB Case Study）：

關鍵架構決策（引述 Chief Architect Rob Gevers）：「Amazon DynamoDB is our primary data layer by default, and teams have to justify the use of something else.」

判讀

Genesys 案例揭露三個 B2B SaaS 平台容量規劃重點。

1. B2B 可用性目標跟 C2C 不同：B2C 大型網站可能接受 99.9%（年停機 8.76 小時）、B2B SaaS 經常合約規定 99.95% 或 99.99%、客服平台類甚至要 99.999%（年停機 5 分鐘）。每多一個 9、容量規劃跟運維成本指數成長。對應 9.12 SLO 與 Performance Budget 的 SLO 等級設計。
2. 「DynamoDB 為預設、用其他要 justify」是規模化平台的工程治理：跟 9.C23 Netflix 整合到 Aurora 是同樣訴求、不同實作 — Genesys 選 DynamoDB 為基準是因為「Multi-region active-active」+「自動 scaling」+「99.999% SLA」的組合最容易達成 5 個 9 目標。對應 01 資料庫模組 的 DB 預設選型。
3. 15 主 region + 5 衛星 region = 全球客戶就近接入：客戶服務有強烈延遲敏感（agent 操作介面卡 1 秒、客服效率掉一半）、必須在客戶所在地有 region。跟 9.C12 Riot Games 246 cluster 的延遲驅動 region 部署同類思維。對應 9.6 容量規劃模型 的地理分散規劃。

需要警惕：

• 「99.999% over 12 months」是 截至特定時間點的歷史值、不代表「未來持續達成」。可用性是滾動指標、不是恆久承諾。
• 案例 沒有 提具體 QPS / RPS、訊息量、延遲分布。讀者要對 策略 學習、具體數字需要自己壓測。

策略

可重用的工程做法：

1. B2B SaaS 平台優先選 multi-region active-active 資料層：DynamoDB Global Tables、Cosmos DB Multi-Region Write、Spanner multi-region 都是候選。對應 01.5 transaction boundary 的全球一致性取捨。
2. 「預設 DB」原則簡化 onboarding：新團隊不用評估十種 DB、預設用 X、特殊需求再 justify。減少團隊認知負擔、加速產品開發。對應 9.C23 Netflix 的 DB 整合。
3. 99.999% 必須有 redundancy 在每一層：DNS、load balancer、application、database、storage 都要跨 region active-active。任何一層 single-region 就破壞整體 SLO。對應 05 部署平台模組 跟 06 可靠性驗證模組。
4. 多 region 是成本 vs 可用性的硬取捨：15 個 region 的成本約是 1 個 region 的 15 倍 — 對 B2B SaaS 是合理投資、對 B2C 通常不划算。

跨平台等效：Azure Cosmos DB Multi-Region Write、GCP Spanner multi-region、Cassandra multi-DC 都可實作對等架構。差異是 region 數量、SLA 承諾、跨 region 延遲。

下一步路由

• 想設計 B2B SaaS 可用性 → 9.12 SLO 與 Performance Budget + 06.6 SLO 與 Error Budget 政策
• 想設計多 region 資料層 → 01 資料庫模組 + 9.C10 Spanner
• 想做 DB 統一治理 → 9.C23 Netflix Aurora consolidation + 00 服務選型模組
• 想規劃跨 region 容量 → 9.6 容量規劃模型 + 9.C12 Riot Games
• 想理解 DynamoDB 99.999% 背後的 partition / GSI 設計 → DynamoDB partition key 反模式 + DynamoDB GSI / LSI 設計
• 想對應 global tables 多 region 寫衝突 → DynamoDB global tables 寫衝突

引用源

• Genesys Achieves 99.999% Availability Using Amazon DynamoDB
• Amazon DynamoDB Customers

觀察

Tubi 在 ElastiCache 的關鍵敘述（引自 ElastiCache Customers）：

判讀

Tubi 案例揭露三個 ML feature store 容量設計重點。

1. feature store 是 ML inference 的 critical path：每個推薦請求都要查 N 個 feature（user_profile、item_metadata、recent_interactions、similar_users 等）、每個 feature 查詢都吃 latency budget。對應 9.12 SLO 與 Performance Budget 的多 stage budget 分解。
2. ScyllaDB → ElastiCache 是「持久 KV → 純 cache」的權衡：ScyllaDB 是 Cassandra-compatible 高吞吐 KV、提供 durability；ElastiCache 是 in-memory cache、可以 cache miss。Tubi 選 cache 是判斷「feature 可以重新計算」、durability 不必、純 in-memory 更快。對應 02 快取模組 的 cache vs durable store 選型。
3. p99 才是 ML 系統的容量門檻：ML 系統的 user-perceived latency 是 最後完成的 inference、不是平均。p50 快沒用、p99 慢用戶就看到 loading spinner。對應 9.4 Saturation Discovery 的 latency percentile 分析、跟 9.C3 Coinbase 的長尾延遲議題同類。

需要警惕：

• 「sub-10ms p99」沒指明 p999 / p9999。p9999 通常比 p99 高一個量級、會出現在實際 user-perceived 體驗。
• ElastiCache 的 sub-10ms 是 cache hit 路徑 — cache miss 路徑會回到 ScyllaDB 或重新計算、延遲可能 100ms+。容量規劃要考慮 cache hit rate 跟 miss recovery 兩條路徑。

策略

可重用的工程做法：

1. ML feature store 用「兩層 cache」設計：L1 是 in-process cache（最熱的 features）、L2 是 ElastiCache / Memcached（次熱）、L3 才是持久 store（ScyllaDB / DynamoDB / S3 + Parquet）。對應 02 快取模組 的 cache hierarchy。
2. feature 可重算 → 用 cache、feature 必須持久 → 用 store：判斷依據是「重算成本」跟「資料一致性需求」。對應 02.4 cache copy freshness boundary。
3. p99 / p999 反推單個 stage latency 上限：每個 stage（network、cache lookup、feature aggregation、model inference、response serialization）給一個 latency budget、總和等於整體 SLO。對應 9.12 SLO 與 Performance Budget、跟 9.C3 Coinbase 同樣的反推思維。

跨平台等效：AWS ElastiCache for Redis / Valkey / MemoryDB、GCP Memorystore for Redis、Azure Cache for Redis 都可實作對等架構。專為 ML feature store 設計的還有 Feast / Tecton / Hopsworks 等開源 + 商業方案、底層常用 Redis-compatible store。

下一步路由

• 想規劃 ML feature store → 02 快取模組 + 9.12 SLO 與 Performance Budget
• 想做 p99 / p999 反推 → 9.C3 Coinbase + 9.4 Saturation Discovery
• 對照其他 cache 案例 → 9.C6 Tinder ElastiCache（配對引擎）
• 想理解 cache hierarchy → 02 快取模組

引用源

• Amazon ElastiCache Customers
• Build an ultra-low latency online feature store for real-time inferencing using Amazon ElastiCache for Redis

觀察

GCP 130K-node GKE cluster 實驗（引自 How we built a 130,000-node GKE cluster）：

工作負載類型：AI / ML 平台、三個 priority class：

• Low：preemptible batch（data prep）
• Medium：core model training（tolerant to queuing）
• High：latency-sensitive inference

關鍵 control plane 設計：

• Consistent Reads from Cache（KEP-2340）— 強一致 read 從 in-memory cache、不打 storage
• Snapshottable API Server Cache（KEP-4988）— B-tree snapshot 處理 LIST 請求
• Spanner-based key-value store 作為 K8s storage backend（撐 13K QPS lease 更新）

判讀

130K-node 案例揭露三個 hyperscale K8s 設計的工程重點。

1. 單一 control plane 的極限取決於 storage backend、不是 nodes：130K node 不是「機器跑不動」、是「API server 跟 etcd 撐不撐住」。GCP 用 Spanner 替換 etcd、配上 cache-first read 設計、把 storage 從瓶頸變成「showed no signs of not being able to support higher scales」。對應 9.5 瓶頸定位流程 的「真實 bottleneck 在哪一層」。
2. AI workload 顛覆了 K8s 容量規劃：傳統 web workload 的 K8s 多在 1K-10K node、節點生命週期長。AI workload 短時間爆量創建跟銷毀 Pods（13 萬個 in 3 分 40 秒）、preempt 跟 schedule 頻繁、對 control plane 是完全不同壓力模式。對應 9.2 Workload Modeling — workload 形狀完全不同、容量規劃也完全不同。
3. 「power constraint > chip supply」是新瓶頸：單顆 NVIDIA GB200 GPU 吃 2700W、萬卡叢集 = 27MW 用電量。未來 mega cluster 必須跨多個 data center（一個 DC 電力撐不住）、需要 robust multi-cluster solutions。這層瓶頸跟 9.7 成本邊界 對接 — 電力成本變成主要 cost driver。

需要警惕：

• 130K-node 是 Google 內部實驗、不是 客戶能用的 production 配置。目前 GKE 官方支援 65K node、客戶用到 100K+ 還很遠。
• AI workload 跟 web workload 完全不同、把 AI 經驗套用到 web service 容量規劃是錯誤類比。

策略

可重用的工程做法：

1. K8s control plane 跟 data plane 分開規劃容量：data plane（worker nodes）擴容容易、control plane（API server、etcd / storage）擴容難。瓶頸通常在 control plane、不是 worker。
2. storage backend 是 K8s 規模極限的關鍵：etcd 撐 5K-10K node 後開始吃力、要用 PostgreSQL / Spanner / 自家 KV 替換、才能擴到萬級節點。一般客戶用不到、但要知道「為什麼到某個規模 etcd 不夠」。
3. AI workload 用 specialized scheduler（Kueue、Volcano）：默認 K8s scheduler 為 web workload 設計、AI 的 gang scheduling、fair-sharing、preemption 都不太適合。對應 05 部署平台模組 的 scheduler 選型。
4. power-aware capacity planning 是未來方向：傳統按 CPU / RAM 規劃容量、未來要加上 power budget。data center 用電量是硬上限、不是錢的問題。
5. multi-cluster 是萬卡訓練的必然：單一 cluster 撐不住、要 MultiKueue 等跨 cluster 排程方案。對應 9.C12 Riot Games multi-cluster 但目的完全不同。

跨平台等效：AWS EKS 官方支援單 cluster 多至 100K pod / cluster、Azure AKS 支援 5K node / cluster。GCP 用 Spanner 替換 etcd 是最深的工程投資、目前其他兩家還沒到這個規模。

下一步路由

• 對照其他大規模 K8s → 9.C12 Riot Games 246 cluster（多 cluster 策略）
• 對照 AI workload → 9.C8 Pokemon GO 50x surge（非 AI 但同 GCP K8s）
• 想理解 control plane vs data plane → 9.C18 Zoom + 9.5 瓶頸定位流程
• 想設計 K8s 容量上限 → 9.6 容量規劃模型 + 05 部署平台模組

引用源

• How we built a 130,000-node GKE cluster
• GKE and Kubernetes at KubeCon 2025
• What’s new in GKE at Next 26

觀察

Snap 在 GCP 的關鍵敘述（引自 Snap deploys KeyDB on Google Cloud、Snap TPU recommendation）：

關鍵架構決策：在 GCP 上部署 KeyDB（Redis fork、multi-threaded）作為 cache layer、減少 cross-cloud latency。

判讀

Snap 案例揭露三個 multi-cloud 容量設計的工程重點。

1. 跨 cloud latency 是隱性容量瓶頸：當 application 在 AWS、cache 在 GCP（或反之）、每個 cache lookup 都吃跨 cloud 網路 latency（通常 5-30ms、視 region pair 而定）。對 Snap 這類「每次互動查多個 cache」 的服務、5ms × 10 cache lookup = 50ms 額外 latency、用戶感受明顯。對應 9.12 SLO 與 Performance Budget 的 latency budget 反推。
2. KeyDB 是 Redis 的 multi-threaded 替代：Redis 7+ 之前是 single-threaded、單實例吞吐受限。KeyDB（Snap 等大型用戶採用）改成 multi-threaded、單實例 throughput 提升 5-10x、適合超高吞吐 cache 需求。對應 9.C6 Tinder ElastiCache 的 cache layer 設計、但 Snap 規模更大要走專業 fork。
3. TPU vs GPU 是 ML training 的容量成本決策：Snap 算過 GPU 的「throughput -67% + cost +52%」就是 TPU 的反向 — TPU 的 throughput 高 67%、cost 低 52% — 對 ML-heavy 公司是巨大決策。對應 9.7 成本邊界與 efficiency 的雲端硬體選型、跟 9.C31 Mercado Libre Vertex AI 的 ML 容量規劃同類。

需要警惕：

• KeyDB 是 fork-based 軟體、有 vendor lock-in 風險（Snap 大規模採用後、KeyDB 公司被收購、未來 fork 走向不確定）
• TPU 是 Google 專屬硬體、不能在其他 cloud 用、是 vendor lock-in 來源
• 「年增 18%」是用戶數、不是流量。流量成長通常超過用戶成長（per-user engagement 上升）

策略

可重用的工程做法：

1. Multi-cloud 架構優先把 cache 跟 application 放同一 cloud：跨 cloud 的不該是 cache lookup（高頻、低 latency 容忍）、應該是 batch sync（低頻、高 latency 容忍）。對應 02 快取模組 的部署策略。
2. Redis 規模化遇到 single-threaded 限制時的選項：
   • 拆 cluster（多個 Redis instance）— 應用層分散 key
   • 換 KeyDB / Dragonfly（multi-threaded fork）
   • 換 Redis 7+ I/O thread（保留 protocol）
   • 換 Memcached（multi-threaded、但功能少）
3. ML training infrastructure 選型按 throughput / cost 而非品牌：GPU vs TPU vs Trainium 不是「哪家好」、是「在 本 workload 上哪個划算」。要實測 benchmark、不是看 vendor marketing。
4. 跨 cloud 部署的「資料引力」：data 在哪、application 通常會被 data 吸過去。Snap 把 cache 放 GCP 是因為 production data 在 GCP — 想搬 cache 到 AWS 同時要搬 data、成本高。

跨平台等效：AWS ElastiCache + Cassandra / DynamoDB Global Tables、Azure Cache for Redis + Cosmos DB 都可實作 multi-region cache 但 single-cloud 內。multi-cloud cache 通常要自管（自管 KeyDB / Dragonfly / Redis Cluster）。

下一步路由

• 對照其他 cache 案例 → 9.C6 Tinder ElastiCache / 9.C25 Tubi ML feature store
• 想設計 multi-cloud cache → 02 快取模組 + 9.5 瓶頸定位流程
• 想做 ML training 容量規劃 → 9.7 成本邊界 + 9.C31 Mercado Libre
• 想理解 cross-cloud latency → 9.12 SLO 與 Performance Budget

引用源

• Snap deploys KeyDB on Google Cloud to reduce cross-cloud latency
• Snap Inc. uses Google Cloud TPU for deep learning recommendation models
• Snap maintains uptime with MCS from Google Cloud
• Why Snap chose BeyondCorp Enterprise

觀察

Coinbase MongoDB 平台的關鍵數字（引自 Coinbase Engineering Blog 與 MongoDB customer case study）：

服務組合：MongoDB Atlas（主資料層）、DynamoDB（部分 workload 的 federated store）、Memcached（query result cache）、自研 mongobetween proxy（連線多工）、Ruby on Rails 單體 + 多個 Fragment APIs、ML 預測模型驅動 cluster auto-scaling。

關鍵負載形狀：「加密貨幣價格突發 + 用戶交易需求湧入」雙峰疊加。價格 alert 觸發 read 爆量（users / portfolio 查詢）、下單觸發 write 爆量（order book / wallet 寫入）。兩種峰值不像 9.C4 DraftKings 的 Super Bowl 事件型可預測、是隨外部市場波動的 low-latency-sustained 中夾雜 surge。

判讀

Coinbase MongoDB 的工程選擇揭露三個 document database 在 production 主角位置的設計重點。

1. MongoDB + Ruby 連線爆炸需要外部 connection pool：CRuby 因為 GVL 必須每 CPU core 起一個 process、blue-green 部署期間 instance 數量 ×2、連線數隨之 ×2、單一 cluster 看到 60K 連線/分鐘。原生 MongoDB driver 沒有跨 process 的 connection pool — 跟 PostgreSQL 走 pgbouncer 是同樣需求、所以 Coinbase 自建 mongobetween 做多工。對應 01.6 高併發資料存取 的 connection storm 問題、document database 不會自動解決、要主動補工具。
2. document model 撐 1.5M reads/sec 靠 cache + freshness token：直接打 MongoDB 不可能撐 1.5M reads/sec — Coinbase 在 users 服務前面加 Memcached query cache、單 document query 先查 cache。但 cache + write 會有一致性問題、所以引入 OCC version 跟 freshness token：write 成功後給 client 一個 token、client 之後 read 帶 token、server 保證返回的資料版本 ≥ token、必要時 bypass cache 直接打 DB。對應 01.5 transaction boundary 的 read-after-write 設計。
3. 加密貨幣 surge 用 ML 預測、不靠 reactive scaling：cluster 擴容要 70 分鐘、傳統 CPU / queue 觸發的 reactive scaling 在 surge 開始時才動、來不及。Coinbase 訓練 ML 模型分析價格資料、提前 60 分鐘預測流量、預先擴容。把擴容時間從 70 分鐘壓到 25 分鐘是 trigger 提前、不是擴容本身變快。對應 9.6 容量規劃模型 的 predictive scaling。

需要警惕：

• 「1.5M reads/sec」是 users 服務 加上 cache 的數字、不是 MongoDB cluster 純讀取數字。讀案例時要區分「應用層觀察到」跟「DB 層實際承擔」。
• mongobetween 是 Coinbase 特殊環境（Ruby + GVL + blue-green）的產物。Go / Java / Node.js 應用因為原生支援連線多工、通常不需要這層 proxy。
• ML 預測有 false positive / false negative — 預測錯時要嘛浪費容量、要嘛 surge 真來時擋不住。Coinbase 沒揭露準確率、所以仍保留 reactive scaling 作為 safety net。

策略

可重用的工程做法：

1. document database 撐大規模 OLTP 要主動補 connection pool：MongoDB 原生 connection 模式對「process 數多 + deploy 重」的環境會爆。應用層或 sidecar proxy 做多工是基線設計。對應 01.10 KV / Document DB 容量規劃。
2. freshness token 是 read-after-write 一致性的可重用模式：比 strong consistency（性能差）跟 eventually consistent（read 不到剛寫的）更精細的中間路徑。token 機制可以推廣到任何「主要 eventually consistent、少數 read 要求最新」的場景。
3. predictive scaling 適用於「外部訊號可預測流量」的服務：加密貨幣價格、賽事行程、票務開賣時間都是外部訊號。比 reactive scaling 早一個擴容週期出手。對應 9.C2 GR8 Tech 的 AI 預測式擴容。
4. federated DB（MongoDB + DynamoDB）按 workload 分流：document-shaped 用 MongoDB、access pattern 固定的 KV 用 DynamoDB。不是「全用 MongoDB」也不是「全遷 DynamoDB」、是按 workload 形狀分。對應 9.C23 Netflix Aurora 的多 DB 整合反例（Netflix 走整合方向、Coinbase 走 federated）。

跨平台等效：

• AWS：MongoDB Atlas + ElastiCache + DynamoDB（Coinbase 配置）
• GCP：MongoDB Atlas on GCP + Memorystore + Firestore（document API）
• Azure：Cosmos DB MongoDB API + Cache for Redis、不需要 Atlas
• mongobetween 風格的 proxy：PostgreSQL 走 pgbouncer / pgcat、MongoDB 走 mongobetween / mongoproxy

下一步路由

• 想規劃 MongoDB 大規模 production → MongoDB vendor page + 01.10 KV / Document DB 容量規劃
• 想做 read-after-write 一致性設計 → 01.5 transaction boundary
• 想做 predictive scaling → 9.C2 GR8 Tech + 9.6 容量規劃模型
• 想對照 MongoDB 遷出 / 保留決策 → 9.C30 Microsoft 365（遷到 Cosmos DB MongoDB API）
• 想理解 connection storm 問題 → 01.6 高併發資料存取
• 想深入 connection / proxy 治理與 cache 層 → MongoDB connection 管理與 cache 層
• 想做 replica set 讀寫分離設計 → MongoDB replica set read preference

引用源

• Coinbase：Scaling connections with Ruby and MongoDB
• Coinbase：Scaling Identity - How Coinbase Serves 1.5M Reads/Second
• Coinbase：How We Do MongoDB Migrations at Coinbase
• MongoDB customer case study：Coinbase Decreases Scaling Time
• mongobetween GitHub repository

觀察

Netflix CockroachDB 艦隊的關鍵數字（引自 Now Streaming: Why Netflix Runs a Fleet of 380+ CockroachDB Clusters / The history of databases at Netflix）：

服務組合：CockroachDB self-managed（Netflix Database Platform Team 自運維）、跨 AWS region、與 Cassandra / EVCache / RDS 並存（polyglot persistence）。

關鍵 workload：

• Studio Cloud Drive：影視製作資產的 file-system 風格服務、需要強一致 metadata + 全球可寫
• Open Connect 控制平面：Netflix 自有 CDN、控制全球網路設備、需要跨 region 一致 control state
• Spinnaker（持續交付平台）：deployment workflow state 需要 transactional 一致
• Maestro（ML / 資料 workflow orchestration）：scheduling 與 state machine 不容許 eventual consistency
• Gaming control plane：metadata 跨 4 region、region failure 不能 downtime

判讀

Netflix CockroachDB 艦隊揭露三個「補 Cassandra 缺口」的 OLTP 工程選擇。

1. Cassandra 不是 transactional 引擎、補位需求是工程現實：Netflix 2014 全面採用 Cassandra 解 global replication、但 lightweight transaction 跟 unreliable secondary index 在 studio / control plane 等場景出問題。2019 評估後選 CockroachDB 是因為它同時滿足 multi-active topology、global consistent secondary index、global transaction、open source、SQL — 五個條件 Cassandra 在 transactional 場景下湊不齊。對應 00 服務選型模組 的 polyglot persistence 與 01.5 transaction boundary。
2. 380+ cluster ≠ 「一個巨型 DB」：Netflix 是 artery of small DBs 模型 — 每個微服務 / 應用配自己的 cluster、cluster sizing 從幾個 node 到 60 nodes 不等。容量規劃變成「每個 cluster 各自規劃」、不是「全公司一個容量曲線」。對應 9.6 容量規劃模型 跟 9.C23 Netflix Aurora 的「微服務私有 store」哲學。
3. Multi-region 是「region failure 0 downtime」、不是「更快」：Netflix 60+ multi-region cluster 主要動機是 region-level survival、不是降 latency（跨 region quorum 反而會增 latency）。Gaming cluster 48-node 跨 4 region 就是為了「region failover 不停服」、不是讓玩家延遲變低。對應 9.12 SLO 與 Performance Budget 的 latency vs availability 取捨。

需要警惕：

• case study 沒揭露單一 cluster QPS / latency 具體數字、只揭露 艦隊規模 跟 最大 cluster 容量。讀案例時不要把「380 cluster」直接換算成「Netflix CockroachDB QPS 上限」。
• Netflix 是 self-managed、不是 Cockroach Cloud — 需要專屬 Database Platform Team 養 380+ cluster。沒這量級團隊的組織直接 self-host 380 cluster 是 ops 自殺、Cockroach Cloud 才是合理路徑。

策略

可重用的工程做法：

1. 不要試圖一個 DB 撐全部：Netflix 同時用 Cassandra（高吞吐 eventual）、CockroachDB（transactional + global）、Aurora（單區 ACID）、EVCache（cache）。每種 DB 對應不同 workload 類型、不混用。對應 00 服務選型模組 的 polyglot persistence。
2. 每個 cluster 對應一個 application boundary：避免 multi-tenant 大 cluster、改用「per-app cluster」— 容量規劃顆粒對齊 application、爆掉時 blast radius 限縮在單一 app。對應 9.5 瓶頸定位流程 的 blast radius 設計。
3. Multi-region 用於 survival、不是 latency 優化：跨 region quorum 物理上必然增 latency。把 multi-region 動機釐清成 region failure 容忍、不要混淆「跨 region = 更快」。對應 1.11 全球分散式 OLTP 的 survival goal vs latency budget 取捨。
4. Self-managed 規模化需要專屬平台團隊：Netflix 有 Database Platform Team 養 380+ cluster — 包含 backup、upgrade、incident response、capacity review。沒這量級團隊就走 managed service。對應 9.7 成本邊界與 efficiency 的人力成本權衡。

跨平台等效：

• Spanner（GCP）解同類「global transaction + secondary index」、GCP-only
• DynamoDB Global Tables 走 eventual consistency、不是 Netflix 想要的 strong consistency
• Yugabyte / TiDB 是 distributed SQL 對等候選、生態深度與 PostgreSQL wire 相容度有差

下一步路由

• 想理解 polyglot persistence 選型 → 00 服務選型模組 + 9.C23 Netflix Aurora
• 想規劃 multi-region survival goal → 1.11 全球分散式 OLTP + CockroachDB vendor
• 對照其他 distributed SQL 案例 → 9.C39 DoorDash / 9.C41 Hard Rock Digital / 9.C10 Spanner
• 想理解 transaction vs eventual consistency 邊界 → 01.5 transaction boundary
• 想深入 CockroachDB survival goal 與 region failure 取捨 → CockroachDB survival goals
• 想規劃跨 region schema 與資料本地化 → CockroachDB locality-aware schema
• 想對比 Aurora DSQL / Spanner / CockroachDB → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• Now Streaming: Why Netflix Runs a Fleet of 380+ CockroachDB Clusters（PDF）
• Now Streaming: Why Netflix Runs a Fleet of 380+ CockroachDB Clusters（cockroachlabs.com Netflix customer page）
• The history of databases at Netflix: From Cassandra to CockroachDB
• A Netflix RoachFest24 Original: The Case for Multi-Region Clusters
• How Netflix engineers choose their tech stack