觀察

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

觀察

Lyft 在 AWS 的關鍵數字（引自 Lyft case study）：

服務組合：Amazon DynamoDB（搭乘追蹤、GPS 座標）、Amazon Redshift（客戶洞察）、Amazon Kinesis（即時事件串流）、AWS Auto Scaling、Amazon EC2 Container Registry。

判讀

Lyft 的工程做法揭露三個微服務容量治理重點。

1. 微服務不是「全部 8x」、是「特定服務 8x」：8x 是 某些核心服務 在週末爆量時刻的擴容比、不是 100 個服務全部 8x。對應 9.5 瓶頸定位流程 必須先做「哪個服務是熱點」的層次定位。
2. 微服務粒度 = 擴容粒度：把 ride matching、payment、driver tracking、notification 切成獨立服務、每個服務的 autoscaling policy 可以獨立設計。對應 03 訊息佇列模組 跟 05 部署平台模組 的服務邊界。
3. GPS 座標寫入 DynamoDB 是高頻 sustained workload：每個 driver 每秒寫 1-2 次位置、200+ 城市 × 每個城市數萬司機 = 巨量持續寫入、跟峰值無關。對應 9.C5 Amazon Ads 的 KV 高吞吐設計同類。

需要警惕：「8x 峰值」是 峰值倍數、不是 尖峰持續時間。週末晚間的尖峰可能持續 3-4 小時、機場特殊事件可能持續 30 分鐘、演唱會結束可能只有 10 分鐘瞬間。容量策略要按持續時間區分。

策略

可重用的工程做法：

1. 微服務粒度切到「同性質擴容單位」：同步 vs async、stateful vs stateless、CPU-bound vs I/O-bound 不該混在同一服務、否則擴容邏輯互相衝突。對應 05 部署平台模組 的 service decomposition。
2. 預測式 + 反應式擴容混用：可預測（早晚通勤）用 scheduled scaling、不可預測（演唱會散場）用 reactive autoscaling、兩者組合。
3. GPS 類持續寫入適合 KV / time-series store：不適合放 OLTP DB、會佔用 transaction 資源。對應 01 資料庫模組 的 storage choice。

跨平台等效：GCP GKE + HPA / VPA / Karpenter、Azure AKS + KEDA、自建 Kubernetes + Cluster Autoscaler 都可以實作對等架構。

下一步路由

• 想做微服務容量治理 → 05 部署平台模組 + 9.6 容量規劃模型
• 想規劃事件型峰值 → 9.11 高峰事件準備 + 9.C2 GR8 Tech
• 想設計高頻 sustained workload → 01 資料庫模組 + 9.C5 Amazon Ads

引用源

• Lyft Case Study
• DynamoDB Customers

觀察

FanDuel 在 AWS 的關鍵敘述（引自 FanDuel Case Study）：

關鍵敘述：「seamlessly scale capacity 5–10 times as required for large sporting events, such as the NFL Super Bowl」。

判讀

FanDuel 案例揭露三個雙重峰值對齊的工程重點。

1. 直播跟投注是兩種完全不同 SLO：直播容忍秒級延遲（用 CDN + ABR 串流）、投注必須毫秒級成交（Super Bowl 進球瞬間、賠率變動、用戶投注必須在賠率變化前完成）。兩個服務必須各自獨立擴容、各自獨立 SLO。對應 9.12 SLO 與 Performance Budget 的多 SLO 對齊。
2. AWS Local Zones / Wavelength / Outposts 是地理 + 監管雙重需求：美國博彩受各州監管、資料必須留在州內 → 用 Local Zones 在每個州就近部署；4G/5G 用戶投注延遲敏感 → 用 Wavelength 在電信商機房內運算；on-prem 需求 → 用 Outposts。對應 9.C14 Standard Chartered 的受監管雙重需求、跟 9.C12 Riot Games 的延遲反推 region。
3. 5-10x 是「同類事件中的最高倍率」：Super Bowl 是 NFL 賽季最大事件、不是常態。平日 baseline → 季後賽 2-3x → 季冠軍賽 4-5x → Super Bowl 5-10x。容量規劃要按事件級別分段、不是一律 10x。對應 9.6 容量規劃模型 的事件型容量分級。

需要警惕：

• AWS 案例 沒有 提具體 betting transaction TPS、concurrent streams、延遲分布。讀者要對 策略 學習、不要套用具體數字。
• 「5-10x」是 峰值倍數、不是 peak 持續時間。Super Bowl 的關鍵 30 分鐘可能 8-10x、其他 3 小時可能 3-5x。

策略

可重用的工程做法：

1. 不同 SLO 的工作負載分開部署、不要混在同一 service：betting 跟 streaming 在 FanDuel 必然是兩個獨立微服務、各自有 dedicated infrastructure。對應 05 部署平台模組 的 service decomposition、跟 9.C7 Lyft 同思維。
2. 多層 edge（Local Zone / Wavelength / Outposts）服務不同延遲需求：Local Zone 服務「州內合規」需求、Wavelength 服務「電信網內超低延遲」、Outposts 服務「on-prem 監管」需求。三者組合對應跨州博彩業務。
3. 事件型容量規劃分級：建立 event tier 體系（regular game / playoff / championship / super bowl），每 tier 對應不同 pre-scale 倍數。對應 9.11 高峰事件準備 的容量分級。

跨平台等效：Azure 提供類似 stack（Stack Edge + Edge Zones + Azure for Operators）、GCP 有 Network Edge + Distributed Cloud。差異是各家 edge 覆蓋深度跟電信商合作。

下一步路由

• 對照其他事件型峰值 → 9.C2 GR8 Tech（賽事高潮 AI 預測）/ 9.C4 DraftKings
• 想設計多 SLO 對齊 → 9.12 SLO 與 Performance Budget
• 想做受監管多地區部署 → 9.C14 Standard Chartered + 9.C12 Riot Games
• 想做 edge / Local Zone 規劃 → 05 部署平台模組
• 想理解雙峰下 Aurora storage / replica scaling → Aurora 儲存層架構 + Aurora read replica scaling
• 想評估 distributed SQL 在 betting 場景的 fit → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• FanDuel Case Study
• FanDuel CloudFront Case Study

觀察

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