Capacity

"Capacity"

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-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/min 的體育博彩金融帳本 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 選擇
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 高峰事件準備活動、季節性流量、推廣事件的 capacity readiness 流程
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-05-12 9.C15 拓元 Tixcraft：售票搶購的瞬間爆量架構拓元用 DynamoDB 當寫入緩衝 + 傳統伺服器當慢速消費者、承受 100K+ 同時選位 + 30 秒從 6 台擴到 800 台
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 億 DAU 的 30 倍突發 Zoom 在 2020 年 COVID 爆發時、日活從 1000 萬衝到 3 億、用 DynamoDB 撐住會議後端
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）