觀察

DraftKings 帳本系統的關鍵數字（引自 DraftKings case study）：

服務組合：Amazon Aurora MySQL-Compatible、Aurora Replicas（讀寫分流）、Aurora I/O-Optimized（2023-05 推出）、Aurora Database Cloning（測試環境）、跨三個 AZ 儲存複製。

關鍵負載形狀：「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」— 比賽進行時是讀爆量、payout event 時是寫爆量、雙峰錯位。

判讀

DraftKings 的工程選擇揭露三個 OLTP 容量設計重點。

1. 200 個獨立資料庫 = sharding 預先做好：按業務切 200 個 cluster、用巨型 cluster 撐全部在這個規模行不通。對應 9.5 瓶頸定位流程 把「單機極限」改成「shard 極限」、每個 shard 的容量規劃變成獨立問題。
2. Replication lag 30 秒 → 10-30 ms：這個改善不只是「快」、而是讓 read-after-write 變得可預測。Aurora 的 storage layer 多 AZ 複製是這個 lag 改善的主因。對應 01 資料庫模組 的 replication lag 影響 transaction boundary 設計。
3. Super Bowl +50% 「no sweat」：這句話的工程意義是 提前做好容量規劃、不是「Aurora 神奇」。寫 workload 預期可能 + 50%、整個 system headroom 預留至少 50%、加上 read replica 動態加減、才能讓 50% 增幅變成「不流汗」。對應 9.6 容量規劃模型 的 headroom budget 與 event-driven scheduled scaling。

需要警惕：100 萬 ops / 分鐘 = ~17K ops / 秒、跨 200 個 databases 平均下來每個 DB 約 80 ops / 秒。這不是「單一 DB 撐 100 萬 ops」、而是「200 shard 加總 100 萬」。讀案例時要看「峰值是分散到多少 shard」、不只看總數。

策略

可重用的工程做法：

1. 按業務切 OLTP cluster、不要一個 DB 撐全部：DraftKings 200 個 databases 顯示「業務切片」是 OLTP 擴容的前置。對應 01 資料庫模組 的 schema design 與 partition 決策。
2. 讀寫分流是 OLTP 容量規劃的基線：6ms 寫 vs <1ms 讀的差距、加上 read replica、是 OLTP 擴容最基本的兩個槓桿。
3. 事件型峰值預測寫進 baseline：Super Bowl 是已知事件、+50% 是歷史經驗、所以可以提前 pre-scale。事件未知（突發新聞、KOL 推廣）的情況才需要 AI 預測（對照 9.C2 GR8 Tech）。

跨平台等效：GCP Cloud SQL + read replica / Spanner、Azure Database for PostgreSQL + read replica、自建 PostgreSQL + Patroni + pgbouncer 都可以實作對等架構。Aurora 的差異是 storage layer 對 replica 的 lag 改善。

下一步路由

• 想規劃 OLTP 高峰容量 → 9.6 容量規劃模型 + 9.11 高峰事件準備 + 01 資料庫模組
• 想搞清楚事件型 vs 突發型峰值 → 9.C2 GR8 Tech 對照
• 想做 read replica 容量設計 → 01.6 高併發資料存取 + 9.5 瓶頸定位流程
• 想理解 replication lag 對 transaction boundary 的影響 → 01.5 transaction boundary
• 想理解 6 寫 / 4 讀 quorum 跟 200 cluster fleet 治理 → Aurora 儲存層架構
• 想規劃 read replica scaling 與 reader endpoint 路由 → Aurora read replica scaling

引用源

• DraftKings Scales Its Financial Ledger with Amazon Aurora
• Aurora I/O-Optimized announcement

觀察

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

觀察

Standard Chartered 在 Aurora 的關鍵敘述（引自 AWS search results 與相關 case study）：

服務組合：Amazon Aurora（PostgreSQL 或 MySQL 相容）、加密 at rest / in transit、多 AZ 部署、跨地區複製（受監管市場各自獨立）。

判讀

受監管銀行案例揭露三個合規驅動容量規劃的重點。

1. 資料駐留限制 = 容量規劃的單位是「per 市場」：7 個受監管市場代表 7 個獨立 cluster（資料不能跨境）、容量規劃變成「7 個獨立規劃 × 各自合規門檻」。對應 00 服務選型模組 的合規要求識別、跟 9.6 容量規劃模型 的地理分片。
2. 「韌性 + 性能」並列、不是 trade-off：傳統工程文化常把可靠性跟性能視為對立、銀行業務要求兩者同時達標。Aurora 的多 AZ storage + replica 同時提供性能（讀分流）跟韌性（故障切換）、達成 韌性即性能 的目標。對應 06.18 reliability metrics governance 的可靠性指標。
3. 遷移本身的合規驗證 = 容量規劃延伸：受監管系統遷移不只是技術測試、還要過合規審查（中央銀行 / 金融監管機關）、每個市場各自審。這個審查 lead time（數月）必須算進遷移時程。對應 01.4 database migration playbook 的合規驅動 migration。

需要警惕：「10x throughput」是 vs 舊系統、不是 vs 競爭對手。受監管銀行的舊系統通常是 1990s-2000s 的 mainframe 或自建 OLTP、性能本來就低。讀案例時要對標的是「自家改善幅度」、不是「絕對性能」。

策略

可重用的工程做法：

1. 資料駐留是容量規劃的硬限制、不是優化選項：受監管市場必須各自獨立 cluster、不能用「全球單一 cluster」優化。對應 00.4 traffic data scale 的合規限制。
2. 多 AZ + 跨地區複製是合規基線、不是優化：銀行業務 RPO / RTO 通常由監管要求（不能丟資料、必須 X 小時內恢復）、不是業務 SLA 選項。對應 06.7 DR rollback rehearsal。
3. 遷移時程要算合規 lead time：每個受監管市場的審查可能 3-12 個月、合計遷移時程是「市場數 × 平均審查月份」、不是「技術遷移月份」。對應 01.4 database migration playbook。

跨平台等效：Azure SQL Hyperscale + Azure regions、GCP Cloud SQL / Spanner + regional configurations、各家雲端的受監管雲端方案（AWS GovCloud、Azure Government、GCP Assured Workloads）都是對等候選。差異是各家對特定監管框架（PCI-DSS、ISO27001、各國金融法規）的認證覆蓋。

下一步路由

• 想規劃受監管產業 OLTP → 00 服務選型模組 + 01 資料庫模組
• 想做合規驅動的容量規劃 → 00.4 traffic data scale + 9.6 容量規劃模型
• 想理解韌性跟性能的同步達成 → 06.18 reliability metrics governance
• 對照其他金融交易案例 → 9.C4 DraftKings Aurora / 9.C3 Coinbase
• 想拆解跨 AZ failover RTO 量級與合規 anti-recommendation → Aurora 跨 AZ failover RTO
• 想評估全球資料常駐與多 region 部署 → Aurora global database 多 region
• 想對照 distributed SQL（CockroachDB / Aurora DSQL / Spanner）的合規場景 → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• Amazon Aurora Customer Stories
• Amazon Aurora for Core Banking Systems
• Amazon Aurora DSQL for global-scale financial transactions

觀察

Netflix 在 Aurora 整合的關鍵敘述（引自 Netflix consolidates relational database infrastructure on Amazon Aurora）：

Netflix 整體 AWS 使用：「Netflix uses AWS to deliver billions of hours of content monthly and runs its analytics platform for optimum performance of its global service. AWS enables Netflix to quickly deploy thousands of servers and terabytes of storage within minutes.」

判讀

Netflix Aurora 整合揭露三個大規模平台 DB 治理重點。

1. 「DB 種類太多」本身是規模化的成本：Netflix 過往用 PostgreSQL、MySQL、Oracle 等不同 RDB、每個都需要不同 DBA 知識、不同備份、不同 monitoring 流程。整合到 Aurora 不只是「換 DB」、是「降低運維 surface area」、釋放工程資源。對應 9.7 成本邊界與 efficiency 的人力成本工程化、跟 9.C19 Capcom 同類訴求。
2. 75% performance improvement 是 Aurora storage layer 的本質優勢：Aurora 把 storage 跟 compute 分離、storage 用分散式 log-based 設計、replication 在 storage 層處理、不在 compute 層 — 這讓 read replica 不會受 master 寫入壓力影響、性能曲線比傳統 RDB 平滑。對應 01 資料庫模組 與 9.5 瓶頸定位流程 的儲存層 vs 計算層分離。
3. Netflix 的 DB 工作負載大多是「微服務私有 store」：Netflix 微服務各自有自己的 Aurora cluster、不共用 — 跟 monolith 「一個大 DB 撐全部」相反。這層架構讓「DB 容量規劃」變成「每個微服務的容量規劃」、複雜度分散。對應 05 部署平台模組 的 service decomposition、跟 9.C7 Lyft 微服務。

需要警惕：

• 「effective 75% improvement」是 跨多個 workload 的最大改善幅度、不是「每個 workload 都 +75%」。實際每個 workload 改善幅度從 10% 到 75% 不等。
• Netflix 數據層遠不止 Aurora — 還有 Cassandra（playback metadata）、EVCache（cache layer）、Iceberg（data warehouse）。Aurora 主要是「需要 ACID 的 OLTP 工作負載」、不是「all-purpose store」。

策略

可重用的工程做法：

1. DB 種類整合是規模化的必要工程：每多一種 DB 就多一套運維 surface。在能合理 consolidate 的時候整合、降低 ops 複雜度。對應 00 服務選型模組 的 vendor diversity 取捨。
2. storage / compute 分離是 OLTP 擴容的關鍵：Aurora、Spanner、TiDB 都採類似設計、是現代 cloud DB 的共同特徵。對應 9.C10 Spanner 的 storage layer 設計。
3. 微服務私有 store 比共用 DB 容量規劃簡單：每個服務各自管 DB 容量、跨服務 contention 變成 network 議題 而非 DB lock 議題。
4. 大規模平台必須區分「OLTP 用 Aurora」「analytics 用 data lake」「KV 用 DynamoDB」「cache 用 EVCache」：Netflix 用各種 DB、不是一招打天下。對應 00 服務選型模組 的 polyglot persistence。

跨平台等效：GCP Spanner（替代 OLTP）+ Bigtable（替代 KV）+ BigQuery（替代 analytics）；Azure Cosmos DB（替代多 model）+ SQL Hyperscale + Synapse — 各雲商提供類似 stack。

下一步路由

• 對照其他大規模平台 → 9.C12 Riot Games EKS（不同 consolidation 策略）
• 想理解 Aurora 設計 → 9.C4 DraftKings Aurora + 01 資料庫模組
• 想做 polyglot persistence 選型 → 00 服務選型模組 + 9.7 成本邊界與 efficiency
• 想做 DB consolidation 規劃 → 01.4 database migration playbook
• 想理解 +75% 的 storage / compute 解耦根因 → Aurora 儲存層架構
• 想規劃自管 PostgreSQL / MySQL 遷入 Aurora 的步驟 → 從自管 PostgreSQL/MySQL 遷入 Aurora

引用源

• Netflix consolidates relational database infrastructure on Amazon Aurora, achieving up to 75% improved performance
• Netflix on AWS
• Netflix Case Study

觀察

Clearent 在 Azure SQL Hyperscale 的關鍵敘述（引自 Clearent Customer Story）：

關鍵特性：Azure SQL Hyperscale 把 storage 跟 compute 分離、跟 9.C23 Netflix Aurora 的 Aurora 是同類設計。

判讀

Clearent 案例揭露三個 Hyperscale 設計的工程重點。

1. 5 億筆 / 年 ≈ 1500 筆 / 秒平均、但 peak 可能 10-50x：支付交易有日內 / 月內 / 季內節律。早上 9-11 點商家對帳高峰、下午 12-1 點消費高峰、晚上 6-8 點消費高峰、月底結算高峰。容量規劃必須按 peak 訂、不是平均。對應 9.2 Workload Modeling 的 peak/avg ratio 跟 9.6 容量規劃模型。
2. Hyperscale = storage / compute 解耦：傳統 SQL Server primary 對 storage 跟 CPU / RAM 綁定、擴 storage 就要換更大 instance、不便。Hyperscale 把 storage 拉到分散式 log service、可以獨立擴 storage（最高 100 TB）、compute 獨立擴。對應 9.C10 Spanner 的同類分離思維、跟 9.C23 Netflix Aurora。
3. 「unite all information in one place」是支付業的特殊需求：merchants 需要對帳、退款、清算、稅務報表都即時可查、不能 OLAP 分開。Hyperscale 的 read scale-out（最多 4 個 secondary replica）讓即時報表跑在 OLTP DB 上不影響交易吞吐。

需要警惕：「scale automatically and almost infinitely」是行銷敘述。實際 Hyperscale 有上限（100 TB storage、Gen5 series 80 vCore）、超過要 sharding 應用層分散。

策略

可重用的工程做法：

1. Hyperscale 跟 Aurora 是同類設計、選型按生態：Azure 生態用 Hyperscale、AWS 生態用 Aurora、GCP 用 AlloyDB / Spanner。三家底層工程哲學一致（log-structured storage、storage / compute 分離）、選哪家取決於 application 已在哪個 cloud。
2. 微服務 + 共用 OLTP 是支付業常見架構：服務拆細、但 OLTP 仍是 single source of truth、共用一個 Hyperscale cluster。這跟 9.C23 Netflix microservice 各自 Aurora 不同 — Netflix 每微服務 自己 Aurora、Clearent 微服務共用 Hyperscale。取捨：Clearent 的「對帳一致性」需求讓共用更划算。
3. 支付業容量規劃以 peak 為主：不能用平均 RPS 規劃、要按單日 / 單秒 peak。歷史 peak × 預期成長 × headroom 是基本公式（9.6 容量規劃模型）。

跨平台等效：AWS Aurora Serverless v2、GCP AlloyDB、Spanner、PostgreSQL 自管 + Patroni 都可實作對等架構。差異是 vendor managed 程度跟 OLAP / OLTP 統一視覺。

下一步路由

• 對照其他 OLTP 案例 → 9.C4 DraftKings Aurora / 9.C23 Netflix Aurora / 9.C14 Standard Chartered
• 想設計支付業容量 → 9.6 容量規劃模型 + 9.11 高峰事件準備
• 想理解 storage / compute 分離 → 9.5 瓶頸定位流程

引用源

• Clearent scales its modern microservices architecture to handle 500 million payment transactions a year
• Announcing Azure SQL Database Hyperscale
• Get high-performance scaling for your Azure database workloads with Hyperscale

觀察

DoorDash 從 Aurora Postgres 遷到 CockroachDB 的關鍵敘述（引自 Why DoorDash migrated from Aurora Postgres to CockroachDB / The New Stack 報導）：

服務組合：Aurora Postgres（遷移前主要 OLTP）、CockroachDB self-hosted、自製 table extraction tool、自製 lossless migration pipeline。

關鍵負載形狀：DoorDash 是 規模化外送平台 — 訂單、Dasher 派遣、餐廳 menu、新業務（grocery / convenience）並存。寫入壓力來自訂單成立、status 變更、地圖位置更新等多種 hot write path。2020 疫情前流量已大、疫情後再翻倍、且高峰集中在週末晚餐 / 週日早午餐時段。

判讀

DoorDash 的工程選擇揭露三個 OLTP 寫入容量設計重點。

1. Aurora 的「single-primary 寫入」是規模化的天花板：Aurora 把 storage 跟 compute 分離、read replica 容易擴、但寫入仍走唯一 primary。1.636 M QPS 不是均勻分佈、是 hot table 集中寫爆。對應 01.6 高併發資料存取 的寫入容量規劃。CockroachDB 改成 Raft per range、每個 node 都能服務寫入、容量隨節點線性擴。
2. Migration 工具自製是先決條件、不是 nice-to-have：DoorDash 沒「一次性遷整套」、而是先寫工具把 table 從主 cluster 拆到獨立 Aurora cluster（紓壓）、再寫第二套工具把 Aurora → CockroachDB（換引擎）。兩階段都要 lossless + 可回退。對應 01.4 database migration playbook 的「先建工具、再遷資料」原則。
3. Cluster 數量增加、alert volume 卻下降：直覺反過來、cluster 多 = 維運面變大、應該更多 alert。但每個 CockroachDB cluster 內建 Raft 自動容錯、單節點 fail 不會 page on-call、Aurora 時代的「primary failover alert」消失。對應 04 可觀測性模組 的「告警 surface 設計」與 06.x reliability 的 graceful degradation。

需要警惕：1.636 M QPS 是 主 cluster 峰值、不是「DoorDash 全部寫入 QPS」。case 沒揭露遷移後單一 CockroachDB cluster 的峰值、只說「跑更多 cluster」。讀案例時不要把這個數字當成「CockroachDB 撐 1.6 M QPS」的證據、它是 Aurora 在那個時間點撞牆的痛點。

策略

可重用的工程做法：

1. single-primary 撞牆前、先評估 multi-primary 選項：Aurora / RDS Postgres 是 single-primary 為主、寫入量持續成長最終會撞天花板。轉折點不是 IOPS、是 primary CPU + WAL flush rate。對應 9.5 瓶頸定位流程 的瓶頸辨識。
2. 遷 OLTP 引擎要走「兩階段紓壓」：先在原引擎內把 hot table 拆出（降低主 cluster 壓力、爭取時間）、再規劃換引擎（架構級改造）。直接「一次性換引擎」風險過高。對應 01.4 database migration playbook。
3. PostgreSQL wire protocol 相容性是降低遷移成本的關鍵：DoorDash 保留 PostgreSQL driver / ORM、應用層改動小。CockroachDB 不是 PostgreSQL fork、是 protocol-level 相容、實際 SQL 行為（serializable default、retry semantics、partial index）仍要驗證。對應 CockroachDB vendor 的 PostgreSQL 相容性 audit 段。

跨平台等效：

• AWS Aurora DSQL（2024）解同類「multi-primary 寫入」問題、但 AWS-only
• Spanner（GCP）同類設計、GCP-only
• TiDB（MySQL wire）解同類問題、亞洲生態深
• 自管 PostgreSQL + Citus（sharded extension）走 application 層 sharding、operation burden 較高

下一步路由

• 想理解 single-primary 寫入天花板訊號 → 9.5 瓶頸定位流程 + 01.6 高併發資料存取
• 想規劃 PostgreSQL → CockroachDB migration → 01.4 database migration playbook + CockroachDB vendor
• 對照其他 OLTP 規模化案例 → 9.C4 DraftKings Aurora（按業務切 cluster）/ 9.C23 Netflix Aurora consolidation（DB 種類整合）
• 想對照其他 distributed SQL 案例 → 9.C40 Netflix CockroachDB fleet / 9.C41 Hard Rock Digital
• 想理解全球一致性 OLTP 選型 → 1.11 全球分散式 OLTP
• 想拆 CockroachDB transaction retry 與 contention 模式 → CockroachDB transaction retry pattern
• 想對比 Aurora DSQL / Spanner / CockroachDB 的選型 → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• Why DoorDash migrated from Aurora Postgres to CockroachDB
• How DoorDash Migrated from Aurora Postgres to CockroachDB（The New Stack）
• How We Scaled New Verticals Fulfillment Backend with CockroachDB（DoorDash Engineering Blog）
• DoorDash Uses CockroachDB to Create Config Management Platform for Microservices（InfoQ）

觀察

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

觀察

Hard Rock Digital sportsbook 部署的關鍵數字（引自 Hard Rock Digital customer page / How Hard Rock Digital built a highly available and compliant sports betting app）：

服務組合：CockroachDB self-managed、AWS US-East-1（共用 control plane）、AWS Outposts（部分州合規要求設備位於州內）、AWS Local Zones（特定都會區延遲補強）。

關鍵 workload：bet placement、bet settlement、account management、cache loading、sports metadata import。

關鍵負載形狀：sports betting 是 event-driven peak — Super Bowl / World Cup 等賽事是已知時間點、流量在開賽前 30-60 分鐘飆升、賽中持續高水位、賽後 settlement 集中爆發。「100 → 33 → 100」的 scale up / down 反映賽季 vs 淡季的容量需求差。

判讀

Hard Rock Digital 的工程選擇揭露三個受監管 OLTP 的設計重點。

1. 法規顆粒決定基礎設施拓樸、不是反過來：美國 Wire Act 要求 betting data 必須在下注州內處理、所以每個營運州都要有州內運算資源。傳統路徑是「每州一個獨立 silo」— 但 silo 之間的玩家統一帳戶、跨州 reporting、欺詐偵測會撞牆。Hard Rock Digital 用 AWS Outposts 把運算放進州內、但邏輯上仍是 一個 CockroachDB cluster — region placement 配置決定哪些 range 釘在哪個 Outpost、合規與單一邏輯 DB 同時成立。對應 01.4 database migration playbook 的合規 boundary 設計與 1.11 全球分散式 OLTP 的 region placement。
2. Survival goal 「Outpost 或 AZ 失敗不丟」對應業務 SLO：sports betting 中 bet placement 不能 lose — 玩家下注後系統 crash 沒紀錄、對博彩牌照是合規事故。CockroachDB Raft 3-replica + 跨 AZ 配置讓 Outpost 失敗時其他 replica 還在、自動 failover。對應 06 reliability 的 RPO=0 設計與 CockroachDB vendor 的 Survival Goals。
3. Scale up / down 是賽季常態、不是異常事件：100 → 33 → 100 的擺盪在 sportsbook 業務是 年度循環 — NFL 季結束 / NBA 季初切換、流量結構性下降。CockroachDB 加減節點靠 range rebalance、不停服。對應 9.6 容量規劃模型 的 seasonality 與 9.11 高峰事件準備 的 event-driven scaling。

需要警惕：

• case study 沒揭露 QPS、p99 latency 具體數字。100 node × 32 vCPU 是硬體規模、不是 throughput。讀案例時要區分 容量 sizing（節點數）跟 workload throughput（每秒處理量）。
• 「省了 10-20 工程師」是 估計差距、不是已 hire 後解雇。對應的是「沒選 PostgreSQL 所以沒招那麼多 DBA」、是機會成本不是節省支出。
• Wire Act 是 美國聯邦法、各州還有獨立法規（NJ DGE、NV NGC 等）。Hard Rock Digital 模型適合 跨州 合規、不是 跨國 — 跨國牌照差異更大、不能直接套。

策略

可重用的工程做法：

1. 合規 boundary 用 region placement 表達、不是 cluster fragmentation：當法規要求資料留某地理邊界、優先看 distributed SQL 的 region placement / pin-to-region 能力、不要直接開獨立 cluster。獨立 cluster 解了合規但破壞了業務邏輯（跨州統一帳戶、欺詐偵測、reporting）。對應 CockroachDB vendor 的 multi-region table 與 Spanner vendor 的 placement。
2. 邊緣硬體（AWS Outposts / Local Zones）是合規工具、不是 latency 工具：Outposts 主要為「資料留某地理邊界」而存在、latency 改善是副作用。決策時先看合規驅動力、latency 改善列為 bonus。對應 05 部署平台模組 的 hybrid cloud 設計。
3. 賽季型擴縮容寫進 baseline 容量模型：Hard Rock Digital 100 ↔ 33 的擺盪不是「臨時 scale up」、是計畫內年度循環。容量規劃要直接把 NFL / NBA / 國際賽事曆塞進預測模型、不要當 surprise。對應 9.6 容量規劃模型 與 9.C2 GR8 Tech 體育博彩 AI 預測。
4. distributed SQL 的 ops 槓桿：team 小、cluster 大：Hard Rock Digital 50 人 tech team 養全部運維、估省了 10-20 個 DBA。distributed SQL 把「DBA 養單區、跨區 sync 養運維」的工作量壓進 系統內建 的 Raft / placement、人月支出降。對應 9.7 成本邊界與 efficiency 的人力成本工程化。

跨平台等效：

• Spanner（GCP）也支援 region placement、但 GCP-only、無 Outposts 等效
• Aurora DSQL（AWS 2024）支援跨 region 強一致、但 Outpost 部署現階段未完整覆蓋
• 自管 PostgreSQL + application 層 sharding：理論可行、operation burden 跟人力需求大幅上升、Hard Rock Digital 評估後選 CockroachDB 的主因之一

下一步路由

• 對照其他受監管金融 / 博彩 OLTP → 9.C14 Standard Chartered（銀行國家層級）/ 9.C4 DraftKings（fantasy sports）
• 對照 event-driven peak 設計 → 9.C2 GR8 Tech / 9.C28 FanDuel
• 想規劃 multi-region OLTP survival goal → 1.11 全球分散式 OLTP + CockroachDB vendor
• 對照其他 distributed SQL 案例 → 9.C39 DoorDash / 9.C40 Netflix / 9.C10 Spanner
• 想理解合規驅動的拓樸設計 → 05 部署平台模組 + 01.4 database migration playbook
• 想拆 CockroachDB survival goal 與合規拓樸對齊 → CockroachDB survival goals
• 想做 region pinning 與在地化 schema → CockroachDB locality-aware schema
• 想對比 Aurora DSQL / Spanner / CockroachDB 給博彩 OLTP → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• Hard Rock Digital: scaling a performant sports betting platform（cockroachlabs.com customer page）
• Hard Rock, anytime, anywhere: scaling a performant sports betting platform（PDF case study）
• How Hard Rock Digital built a highly available and compliant sports betting app
• Building a sports betting application to handle ‘Big Game’ traffic
• CockroachDB for Gambling solutions page