Tarragon

"Capacity"

• 2026-10-15 9.0 請求路徑上的負載分析：一次一筆的處理、在它之前能回應的請求、多出來的請求怎麼處置、保護把負載轉到哪裡、重送與去重，以及保護元件與依賴故障時的處置 沿著一個會改變狀態的請求從用戶端到資料庫的路徑分析負載時共用的幾個概念：必須一次只處理一筆的那件事與它的互斥範圍、需要經過它的請求裡結果事先已確定的比例、多出來的請求要排隊、拒絕還是請使用者重新確認、每一段保護把負載轉給了哪個元件（保護元件自己的狀態、連線數、輪詢、下游接收端、外部配額）、佇列與重按帶來的重送怎麼去重、保護元件故障或輸出錯的值時下游讀到什麼，以及依賴變慢、部分失效與恢復時的第二波湧入
• 2026-10-15 9.0.1 售票搶購的負載路徑：熱點列與連線池、CDN 合併回源、排隊放行的速率、資料庫認領與加入 Redis 閘門的條件、付款期限的條件更新 以售票搶購為例，沿著一張票從座位圖到付款記帳的路徑，寫出全部請求更新同一個庫存計數時熱點列與連線池的耗盡順序，邊緣快取、排隊放行、資料庫逐張認領與加入 Redis 扣庫存各自把負載轉給了哪一段、自己出錯時由哪一段補救，以及成功請求的總數有上限、延遲不改變請求的價值、先到先得這幾個前提讓哪些做法可以簡化、哪些需求無法簡化
• 2026-10-15 9.0.2 交易撮合的負載路徑：閘道的帳戶限流與明確拒絕、依序日誌的複寫延遲、單一寫入者的撮合引擎、行情的合併送出與重放驗證容量 以交易撮合為例，沿著一筆委託從入口閘道到成交回報的路徑，寫出撮合之前結果無法確定、處理順序決定成交、延遲改變請求的價值這些性質讓哪些負載保護不能用，閘道、依序日誌、單一寫入者的撮合引擎與行情發布各自先耗盡的資源與出錯時的補救，過載時明確拒絕超量委託與以重放驗證容量的做法，並與售票搶購對照
• 2026-10-28 JMeter 在容量探測的用法：thread group 固定的負載變數、逐級加壓、knee 的判讀、施壓端與分散施壓的檢查、多 protocol 的涵蓋範圍與排查順序 用 JMeter 找飽和點時的判斷：thread group 與 timer 量的是哪一種負載模型、Open Model Thread Group 的逐級加壓、從 dashboard 判讀 knee、施壓端與 TLS 連線的失真、分散施壓，以及容量結論要附的條件
• 2026-10-28 Locust 在容量探測的用法：closed model 下的逐級加壓、吞吐量與延遲的換算、pacing 的上限、worker 的檢查與排查順序 Locust 只有 closed model 時找飽和點的判斷：逐級增加使用者、從每秒 task 數與延遲換算受測服務的狀態、到達率型服務的延遲低估與 pacing 的上限、worker 與 client 的排除條件，以及容量結論的寫法
• 2026-10-27 Gatling 在容量探測的用法：open model 的逐級加壓、knee point 的判讀、施壓端的檢查、feeder 資料的分佈與排查順序 用 Gatling 找受測服務飽和點時的判斷：逐級加壓的兩種注入寫法與各自適用的階段、report 的四張圖怎麼換算成受測服務的狀態、施壓端要先排除的資源與 OSS、Enterprise 的分散施壓、feeder 資料怎麼讓容量估高、讀寫高峰錯開時的 scenario 寫法，以及容量結論要附的執行條件
• 2026-05-12 9.1 壓測理論與系統行為 Little's Law、queueing theory、USL、saturation curve 在容量規劃中的角色
• 2026-05-12 9.C1 AWS Prime Day 2025：可預期極端峰值的 dogfood Amazon 自家服務在 Prime Day 2025 的峰值數字 — 一年一次可預期峰值的容量設計參考
• 2026-09-24 服務規模成長的閱讀路線：架構撞到限制的訊號、要補的能力與對應章節 一個服務從一臺機器演進到多區域多服務的過程裡架構撞到限制的訊號、每個訊號對應要補的能力與章節，以及入門影片常用的比喻各對應到哪一篇
• 2026-07-06 資料模型與容量邊界 raw log 表的欄位怎麼設計才好彙總、以及 Sheets 累積到多少列會開始撐不住、撐不住的訊號長什麼樣
• 2026-05-12 9.2 Workload Modeling 把 production traffic shape 翻成可重播的壓測模型
• 2026-05-12 9.C2 GR8 Tech：AI 預測式自動擴容下的體育博彩高峰 AI 預測 + EKS 自動擴容怎麼在 25ms p95 下承載 54000 TPS 體育博彩峰值流量
• 2026-05-12 9.3 壓測工具選型 k6 / JMeter / Gatling / Locust / Vegeta / Production Replay 的工程選型
• 2026-05-12 9.C3 Coinbase International Exchange：超低延遲交易的逆向容量設計 為什麼 Coinbase 國際交易所選 Cluster Placement Group + z1d 而不是自動擴容 — 延遲敏感型負載的容量取捨
• 2026-05-12 9.4 Saturation Discovery 找出 throughput plateau 與 latency knee 的方法
• 2026-05-12 9.C4 DraftKings：Aurora 處理每分鐘 100 萬 ops 的體育博彩金融帳本 DraftKings 用 Aurora MySQL 跑體育博彩金融帳本、Super Bowl 流量 +50% 不影響延遲
• 2026-05-12 9.5 瓶頸定位流程 從 app 到 DB / cache / broker / 第三方 quota 的逐層瓶頸定位
• 2026-05-12 9.C5 Amazon Ads：DynamoDB 9000 萬 reads/sec 的廣告事件量測 Amazon Ads 在 DynamoDB 上跑 9000 萬 reads/sec + 500 萬 writes/sec、99.999% 可用性的廣告事件量測
• 2026-05-12 9.6 容量規劃模型 peak forecast、headroom budget、growth curve、autoscaling sizing
• 2026-05-12 9.C6 Tinder：ElastiCache for Valkey 承載 4700 萬月活的配對引擎 Tinder 用 Amazon ElastiCache for Valkey 提供配對引擎所需的次毫秒延遲快取層
• 2026-05-12 9.7 成本邊界與 efficiency cost per request、cost curve、降級成本、over-provisioning trade-off
• 2026-05-12 9.C7 Lyft：100+ 微服務在 8 倍峰值下的 Auto Scaling Lyft 用 AWS Auto Scaling 跨 100+ 個微服務承載 8 倍峰值流量、跨 200+ 城市
• 2026-05-12 9.8 效能可觀測性 saturation metric、USE / RED method、cost dashboard
• 2026-05-12 9.C8 Niantic Pokémon GO：在 GCP 上承載 50 倍突發流量 Pokémon GO 上線時實際流量達原始預估 50 倍、Google CRE 怎麼即時補容量
• 2026-05-12 9.9 Performance Improvement Loop 壓測 → profile → fix → re-test → release gate 的閉環
• 2026-05-12 9.C9 Spotify：從自管 Kafka 遷移到 GCP Pub/Sub 的事件交付系統 Spotify 把自管 Kafka 事件系統遷移到 Google Cloud Pub/Sub、避免自管 broker 的容量規劃成本
• 2026-06-22 Prometheus 容量規劃與故障模式 說明 Prometheus 單機容量邊界、cardinality 與 retention 的資源模型、常見故障模式與判讀方式
• 2026-05-13 1.10 KV / Document DB 容量規劃 DynamoDB / Cosmos DB / Bigtable / MongoDB 等 KV / Document DB 的容量設計、partition key 取捨、capacity mode 選擇，以及加 region 之後寫入容量怎麼跟著乘上去
• 2026-05-12 9.10 Production-Side 驗證 shadow traffic、dark launch、canary、production-like load test
• 2026-05-12 9.C10 Cloud Spanner：每秒 10 億請求的全球一致性資料庫 Google Cloud Spanner 內部峰值 10 億 req/sec、跨地區強一致 — 全球分散式 OLTP 容量參考
• 2026-05-12 9.11 高峰事件準備 可預期峰值從 T-90 到 T-0 的準備時程：容量計畫、quota 申請、壓測、game day 與 pre-scaling 各排在事件前幾天、排在那裡的理由與項目之間的依賴，pre-scaling 的做法、watch room、event tier 分級與準備時間不夠時被壓縮的部分，以及事後 retro
• 2026-05-12 9.C11 Minecraft Earth：Azure Cosmos DB 上的全球分散式 AR 遊戲 Minecraft Earth 用 Cosmos DB 跨地區分散、測試到 100 萬 RU/s 仍維持承諾延遲
• 2026-05-12 9.12 SLO 與 Performance Budget performance budget 跟 SLO / error budget 的對接
• 2026-05-12 9.C12 Riot Games：246 個 EKS cluster 的多遊戲多地區治理 Riot Games 從 Mesos 遷移到 EKS、用 246 個 cluster 跨遊戲跨地區治理、年省 1000 萬美金
• 2026-05-12 9.C13 Disney+ Hotstar：IPL 板球決賽 1860 萬人同時直播 Hotstar 在 IPL 板球決賽創下 1860 萬同時觀看的全球直播紀錄、CDN 與全球邊緣容量極限
• 2026-05-12 9.C14 Standard Chartered：受監管銀行的 Aurora 4000 TPS 容量提升 Standard Chartered 銀行遷移到 Aurora 後吞吐量提升 10 倍至 4000 TPS、跨 7 個受監管市場
• 2026-10-02 9.15 無預警瞬時大流量：流量來源辨識、擴展緩衝、請求優先等級、准入控制、體積型攻擊與退路 沒有準備窗口的瞬時大流量（突發流量、流量暴增）怎麼承接：依流量形狀分辨真人需求、應用層的濫用流量、體積型攻擊（DDoS），自動擴展的反應時間換算成緩衝，入口標記請求優先等級與負載卸除的順序，等候室與事前註冊這類准入控制，把體積型攻擊交給更大的邊緣網路，以及擴展跟不上時的退路
• 2026-05-12 9.C15 拓元 Tixcraft：售票搶購的瞬間爆量架構 拓元把售票系統搬到 AWS 後，30 分鐘內把資源擴到 130 倍（一場熱門活動擴到 800 台 EC2），處理 10 萬以上同時在線與每秒 2,500 筆以上訂單；資料庫改用 DynamoDB
• 2026-10-14 9.16 負載超過容量時服務的表現：變慢、請求失敗、無回應、程序終止，尖峰過去或應對切換之後仍持續的停在失效、擺盪與第二波湧入，以及應對選出的降級回應，各自的判斷標準、成因、應對與看得到它的監控層 負載超過容量（過載）時，服務呈現的結果分成變慢、請求失敗（抵達後被拒與根本沒有抵達）、無回應、程序終止，以及尖峰過去、依賴恢復或應對切換之後仍持續的停在失效、擺盪與第二波湧入；每一種的判斷標準、通常的成因與應對，哪一種先出現由先耗盡的資源與等待是否設有上限決定，影響範圍怎麼隨時間擴大，服務端監控的各層各自看得到哪一種，降級回應怎麼計數，過載在資料上造成的重複寫入、接受後遺失與讀到舊資料，以及描述一次過載要寫出的項目
• 2026-05-12 9.C16 SeatGeek：DynamoDB + Lambda 打造的虛擬等候室 SeatGeek 用 DynamoDB 4 張表 + Lambda Bouncer 實作 flash-sale 的准入控制（等候室）、取代第三方 waiting room 服務
• 2026-05-12 9.C17 BookMyShow：印度年售 2 億張票的資料架構現代化 BookMyShow 從 15 年自建 analytics 遷移到 AWS modern data architecture、4 個月完成、分析成本下降 80%
• 2026-05-12 9.C18 Zoom：COVID 期間每日會議參與人次從 1000 萬到 3 億的 30 倍成長 Zoom 在 2020 年初每日會議參與人次從 1000 萬增加到 3 億，會議後端用 DynamoDB 全域表與隨需容量模式承接
• 2026-10-06 1.19 資料表長期成長的成本：查詢讀的量、列表的部分索引、查詢以外的成本、分割與唯一約束、批次資料的共用欄位 哪些表會隨營運年數一直變大、怎麼判斷一條查詢讀的量跟著回傳筆數還是跟著表的大小、列表排除大宗資料時排除條件與索引的位置、表變大之後在查詢以外增加的成本與該量的指標、依時間分割與唯一約束的衝突，以及同一批建立的資料共用欄位的存放位置；附 PostgreSQL 17 的實測
• 2026-05-12 9.C19 Capcom：Resident Evil / Monster Hunter 在 DynamoDB + EKS 上的遊戲後端 Capcom 把 Resident Evil、Street Fighter、Monster Hunter 遊戲後端跑在 DynamoDB + EKS、單一秒位數延遲、營運成本降 30%
• 2026-05-12 9.C20 Zomato：從 TiDB 遷移到 DynamoDB、吞吐 4 倍、延遲降 90%、成本減 50% Zomato 帳單系統從 TiDB 遷移到 DynamoDB、吞吐 2K→8K RPM、延遲降 90%、成本減 50%
• 2026-05-12 9.C21 ASOS：Cosmos DB 在 Black Friday 處理 1.67 億請求 ASOS 在 2016 Black Friday 用 Azure Cosmos DB 在 24 小時內處理 1.67 億請求、3500 req/sec、48ms 平均延遲
• 2026-05-12 9.C22 Wayfair：用 GCP 提供 Way Day / Black Friday 的 burst capacity Wayfair 22M+ 商品 + 16,000+ 供應商、用 GCP 補充 on-prem data center 在峰值事件的 burst capacity
• 2026-05-12 9.C23 Netflix：把關聯式 DB 統一到 Aurora、效能 +75%、成本 -28% Netflix 把多套關聯式 DB 統一到 Aurora、效能提升 75%、成本下降 28%、串流數十億小時
• 2026-05-12 9.C24 Genesys：用 DynamoDB 在 15 region 跑出 99.999% 可用性 Genesys 客服平台用 DynamoDB 為預設資料層、跨 15 主 region + 5 衛星 region、達成 12 個月 99.999% 可用性
• 2026-05-12 9.C25 Tubi：從 ScyllaDB 遷到 ElastiCache、ML feature store 達 sub-10ms p99 Tubi 把 ML 推薦的 feature store 從 ScyllaDB 遷到 ElastiCache for Redis、99 百分位延遲降到 10ms 以下
• 2026-05-12 9.C26 PayPay：行動支付每日 3 億訊息的 DynamoDB 後端 日本最大行動支付 PayPay 每日 3 億訊息、用 DynamoDB 處理通知與訊息功能、支撐次秒級反應
• 2026-05-12 9.C27 Disney+：DynamoDB 承載每日數十億動作的觀看歷史 Disney+ 用 DynamoDB 承載每日數十億動作的觀看歷史、watchlist、播放進度等串流 metadata
• 2026-05-12 9.C28 FanDuel：體育直播 + 投注的雙重峰值 FanDuel 3.5M MAU、Super Bowl 期間擴容 5-10 倍、用 AWS Local Zones + Wavelength + Outposts 處理 20+ 州的雙重峰值
• 2026-05-12 9.C29 NTT DOCOMO Lemino：3 個月達 500 萬 MAU 的串流後端 Lemino 用 DynamoDB + AWS Media Services 承載 30 channels live + 5M MAU、工程工時下降 90%
• 2026-05-12 9.C30 Microsoft 365：從 MongoDB 遷移到 Cosmos DB 的分析平台 Microsoft 365 把使用分析平台從 MongoDB 遷移到 Cosmos DB、planet-scale 全球分散式分析
• 2026-06-02 Aurora Serverless v2 適用判斷：ACU 自動擴縮、混合 cluster 與何時不該用 Aurora Serverless v2 不是「比較便宜的 Aurora」；本文展開 ACU 計費粒度、秒級自動擴縮機制、min/max ACU 設定、serverless 與 provisioned 同 cluster 混用，以及穩定高負載下 serverless 反而更貴的成本 crossover 邊界
• 2026-05-12 9.C31 Mercado Libre：LatAm 電商在 GCP 上用 Vertex AI 搜尋 1.5 億商品 Mercado Libre 1 億客戶 + 1.5 億商品、用 GCP Vertex AI Search + BigQuery 提供近即時搜尋與分析
• 2026-05-13 9.C32 Clearent：Azure SQL Hyperscale 處理每年 5 億筆支付交易 Clearent 在 Azure SQL Hyperscale 上處理每年 5 億筆支付交易、autoscale + 微服務架構
• 2026-05-13 9.C33 Maersk + Bosch：傳統產業在 Azure AKS 上的微服務治理 全球海運 Maersk 跟 Bosch 智慧建築把 AKS 當微服務治理基礎、釋放工程資源做業務功能
• 2026-05-13 9.C34 GCP：130,000-node GKE cluster 的工程極限 Google 用單一 GKE control plane 跑 13 萬個 node、AI workload + 1000 Pods/sec 創建吞吐
• 2026-05-13 9.C35 Snap：GCP + KeyDB 在 multi-cloud 架構下的低延遲快取 Snap 用 GCP 上的 KeyDB cluster 減少跨 cloud cache 延遲、用 TPU 訓練廣告推薦模型
• 2026-05-26 9.C36 Coinbase：MongoDB 作為 Ruby 單體與 1.5M reads/sec identity 服務的主資料庫 Coinbase 以 MongoDB 為主資料層、自建 mongobetween connection proxy、users 服務在加密貨幣 surge 時處理 1.5M reads/sec
• 2026-05-26 9.C37 Forbes：自管 MongoDB → Atlas on GCP、build 時間 25 → 9 分鐘 Forbes 把自管 MongoDB 遷到 Atlas on Google Cloud、6 個月完成、build 25 → 9 分鐘、120M 不重複訪客單月承接
• 2026-05-26 9.C38 Toyota Connected：以 MongoDB Atlas 作為 900 萬車輛 telematics 的資料層、月 180 億 transaction Toyota Connected 以 MongoDB Atlas 作為 Safety Connect 900 萬車的資料層、月 180 億 transaction、緊急訊號 3 秒內到 agent
• 2026-05-26 9.C39 DoorDash：Aurora Postgres 寫入瓶頸 → CockroachDB 多主寫入 DoorDash 從 Aurora Postgres 遷到 CockroachDB、解 1.6 M QPS 單主寫入瓶頸、外送平台爆量壓力下重做 OLTP 拓樸
• 2026-05-26 9.C40 Netflix：380+ CockroachDB cluster 的 multi-active 拓樸艦隊 Netflix 把 Cassandra 不夠用的 transactional workload 移到 CockroachDB、380+ cluster / 60+ 跨 region、含 Open Connect、studio cloud drive、gaming control plane
• 2026-05-26 9.C41 Hard Rock Digital：CockroachDB on AWS Outposts、Wire Act 合規 + 跨州單一邏輯 DB Hard Rock Digital 用 CockroachDB 跨 AWS Outposts + US-East-1、Wire Act 強制資料留州、單一邏輯 DB 解多州 sportsbook、以 100 node 32 vCPU 處理 Super Bowl 的投注尖峰
• 2026-05-27 Aurora Read Replica Scaling：15 replica 上限、lag profile、headroom 預留與 fleet 治理 Aurora 15 replica 上限、共享 storage 為什麼能養大量 replica、事件型容量分級表、DraftKings headroom 預留判讀、FanDuel 雙 SLO 並行、fleet 治理 3 條 driver（business sharding / microservice / 合規）
• 2026-05-19 JMeter → k6：k6 不是 JMeter 的「script 版本」、是 VU model 取代 thread model JMeter → k6 是 Type E paradigm shift、不是把 .jmx XML 翻成 JavaScript — VU (virtual user) model 跟 thread group model 是兩種對「使用者行為」不同的建模方式。本文走 6 維 audit（Schema High / Paradigm High / Operational Medium）、釐清反向定義、4-phase partial migration（多數 org 停 Phase 2-3 hybrid）、5 production 踩雷（thread group 翻譯失真 / arrival rate vs concurrent VU 混淆 / protocol gap / 結果 schema 改 / CI integration 重做）、protocol gap（JDBC / JMS / LDAP 在 k6 沒原生對應）、何時不要切
• 2026-05-19 Pyroscope → Datadog Continuous Profiler：profiling deployment lifecycle 各階段 operational ownership 轉手 Pyroscope → Datadog Continuous Profiler 是 Type C operational hybrid migration — pprof data model 接近、profile lifecycle 五階段（install / instrument / ingest / query / cost）的 ops ownership 從 self-host 轉到 SaaS。本文走 6 維 audit（Operational High 其他 Low）、4-phase migration（operational audit + agent parallel + tag reconcile + cutover）、5 production 踩雷（agent 重複 overhead / tag schema 不一致 / trace_id correlation 斷 / cost 突增 / retention 政策變動）、何時保留 Pyroscope（資料主權 / 內網 / OSS-first / cost sensitive）