觀察

BookMyShow 在 AWS 的關鍵敘述（引自 BookMyShow AWS Migration Blog）：

資料架構：

• Data Lake：Amazon S3 統一儲存
• Ingestion：Kafka consumers、AWS Glue ETL、AWS IoT Core（MQTT）
• Processing：Amazon EMR（streaming permanent cluster + batch transient cluster）
• Data Warehouse：Amazon Redshift + materialized views
• Analytics：Amazon Athena（ad-hoc）+ Amazon QuickSight（dashboard）
• ML：Amazon SageMaker（內容熱度、活動熱度、搜尋趨勢模型）
• Orchestration：Amazon MWAA + AWS Step Functions

關鍵業務支撐：「sudden spikes with new movies or events launched」靠 serverless（S3、Glue、Athena、Step Functions、Lambda）自動擴容、無需人工介入。

判讀

BookMyShow 案例揭露三個規模化 ticketing 平台的長期工程重點。

1. 單一搶票 → 常態多事件 = 架構從「為峰值設計」變「為流量分佈設計」：每天上百場電影 + 數十場演唱會 + 各種活動同時開票、每場都是 mini flash-sale。容量問題不再是「為一場演唱會準備」、而是「為每天上百個峰值同時準備」。對應 9.2 Workload Modeling 從單一 workload 變成 workload portfolio。
2. 資料層比交易層更難擴：8 TB → 80 TB 過程中、舊 analytics 系統用 15 年才走到極限。交易層擴容靠 stateless EC2 + auto-scaling 相對容易、資料層 schema migration、ETL 重寫、報表回對都是長 lead time 工作。對應 01 資料庫模組 的 schema migration 與 04 可觀測性模組 的 cost attribution。
3. 跨國市場 = 多重合規約束：印度、新加坡、印尼、中東各自有資料駐留 / 加密 / 報稅規則。S3 + EMR + Redshift 的「資料分區」不只是性能議題、也是合規議題。對應 9.C14 Standard Chartered 的合規容量規劃。

需要警惕的判讀盲點：

• 「年售 2 億張」是 年度總和、不是 峰值。實際單秒峰值（板球比賽決賽開票、寶萊塢新片首映）案例本身沒揭露。
• 案例聚焦在 資料分析層 的遷移、不是 交易層 的 flash-sale 設計。讀者若想學「單場 flash-sale 怎麼撐」、應該回 9.C15 Tixcraft 或 9.C16 SeatGeek。
• 「80% 成本下降」是 vs 15 年舊系統、不是 vs 競爭對手。舊系統的儲存效率、運維成本本來就低、改善幅度部分來自「現代化紅利」、不只是 AWS 服務本身。

策略

可重用的工程做法：

1. 大規模 ticketing 平台要分「交易層」跟「資料層」兩條容量規劃：交易層為單一 event flash-sale 設計（9.C15 / 9.C16 模式）；資料層為「上千場活動的長期分析」設計（BookMyShow 模式）。兩者用不同服務、不同 SLO。
2. 跨國平台先解決資料駐留、再規劃跨國 analytics：印度資料不能搬到新加坡分析、合規必須各國資料本地處理、再彙整 metadata。對應 9.C14 Standard Chartered。
3. serverless data stack 是 ticketing 平台的長期方向：S3 + Glue + Athena + Step Functions 的成本曲線比 EMR cluster 平穩、沒事件時近乎 0、有事件時自動擴。對應 9.7 成本邊界與 efficiency。
4. 遷移時程 4 個月 = 計畫密度極高：15 年資產 4 個月遷完不是常態、需要先把 資料模型 canonical 化、再 batch 平行遷。對應 01.4 database migration playbook 的 schema 對映先行。

跨平台等效：GCP BigQuery + Dataflow + Cloud Storage + Pub/Sub 是對等 stack；Azure Synapse + Data Lake + Event Hubs；自建 Delta Lake + Spark + Kafka 都可以實作對等架構。差異是 vendor 整合度跟 serverless 透明度。

下一步路由

• 想規劃多事件 ticketing 平台 → 9.2 Workload Modeling + 01 資料庫模組
• 想看單一 flash-sale 設計 → 9.C15 Tixcraft + 9.C16 SeatGeek
• 想做跨國合規容量規劃 → 9.C14 Standard Chartered + 00 服務選型模組
• 想做大規模 migration → 01.4 database migration playbook + 9.C9 Spotify migration

引用源

• How BookMyShow saved 80% in costs by migrating to an AWS modern data architecture
• AWS Modern Data Architecture

觀察

Wayfair 在 GCP 的關鍵敘述（引自 Wayfair Case Study）：

服務組合：BigQuery（資料倉儲）、Cloud Dataproc（資料處理）、Cloud Pub/Sub（資料注入）、Looker（dashboard）、Cloud DLP（合規）、C2 processors（高性能 compute）。

關鍵敘述：「Our automation systems signal the cloud to scale on demand」「We were able to reduce and eventually eliminate the need for change freezes leading up to big events」。

判讀

Wayfair 揭露三個 hybrid cloud burst 模式的工程重點。

1. Hybrid burst 是「容量規劃成本平衡」的折衷：自家 data center 平日跑得便宜、峰值事件不夠用；全部上雲峰值好辦但平日成本高。Hybrid 模式讓 baseline 用便宜的、峰值用彈性的、總成本曲線最平。對應 9.7 成本邊界與 efficiency 的長期 TCO 規劃。
2. 「Change freeze 不再需要」是 burst 模式的真正價值：傳統零售 IT 為了 Black Friday 通常 2-3 個月前就 freeze code change、確保穩定。Wayfair 在 GCP burst 上線後、能在峰值前繼續正常 release — 因為新功能可以單獨 deploy 到 GCP、不影響 on-prem 主系統。對應 06.8 release gate 的非凍結式變更管理。
3. 資料平面（BigQuery / Dataproc）是 hybrid 的主場、交易平面仍在 on-prem：Wayfair 把「分析、報表、推薦模型」放 GCP、「核心交易、訂單處理、庫存」仍在自家。這個切分是 hybrid 的常見做法 — 計算密集的工作上雲、業務核心保留自管。對應 01 資料庫模組 的核心 OLTP 跟 04 可觀測性模組 的分析資料層分離。

需要警惕：

• Wayfair 案例 沒有 提具體 TPS、latency、capacity scale 數字 — 行銷敘述居多、工程細節較少。讀此類案例要對 策略 做學習、不要套用具體數字。
• 「82.5% 美國淨營收成長」是 業績、不是 系統指標。系統能撐業績、但兩者不是同一件事。

策略

可重用的工程做法：

1. Hybrid burst 適合「業務核心 on-prem 已穩定 + 季節性 / 事件型峰值」的企業：對於全新雲原生 startup、直接全上雲更簡單；對於有 15-20 年自建系統的大企業、hybrid 是穩妥路徑。
2. 資料平面先上雲、交易平面後上：BI、ML、推薦這類「計算密集 + 資料量大 + 容忍延遲」適合先上 GCP / AWS / Azure；OLTP 後續再評估。對應 9.C17 BookMyShow 的資料層先行模式。
3. automation signal + 雲端 burst 是「change freeze」的解法：監控訊號 → 自動 trigger 雲端容量 → 平滑釋放 → 不影響 on-prem 主系統的部署節奏。對應 9.11 高峰事件準備。

跨平台等效：AWS Outposts + AWS Direct Connect、Azure Arc + ExpressRoute、Equinix + 各雲商 PrivateLink 都是 hybrid burst 的基礎設施。差異是各家 hybrid 策略成熟度。

下一步路由

• 想規劃 hybrid cloud burst → 9.6 容量規劃模型 + 9.11 高峰事件準備
• 想做資料平面遷移 → 9.C17 BookMyShow + 01 資料庫模組
• 對照全雲原生 → 9.C15 Tixcraft
• 想取消 change freeze → 06.8 release gate + 06.17 feature flag governance

引用源

• Wayfair Case Study (Google Cloud)
• Way Day 2019 burst capacity

觀察

Microsoft 365 在 Cosmos DB 的關鍵敘述（引自 Microsoft 365 boosts usage analytics with Azure Cosmos DB）：

關鍵敘述：「The team decided to replace MongoDB with Azure Cosmos DB, a fully managed globally-distributed, multi-model database service designed for global distribution and virtually unlimited elastic scalability.」

判讀

Microsoft 365 案例揭露三個全球 SaaS 分析平台的工程重點。

1. MongoDB → Cosmos DB 是「相容 API + 升級擴展性」的遷移路徑：Cosmos DB 提供 MongoDB API 相容、應用層程式幾乎不用改、但底層儲存改用 Cosmos DB 的分散式架構。這層遷移成本遠低於改寫 application 到 native Cosmos DB SQL API、適合大規模既有系統。對應 01.4 database migration playbook、跟 9.C20 Zomato 形成對照。
2. 分析平台 vs 交易平台的 DB 取捨不同：交易平台優先 latency + consistency（9.C10 Spanner）、分析平台優先 throughput + global distribution + cost。Cosmos DB 5 個 consistency level 讓分析場景可以選 weakest（eventual / session），換最大 throughput。對應 9.C11 Minecraft Earth 同思維。
3. Microsoft 自家產品 dogfood Cosmos DB：跟 Amazon Prime Day 用自家 DynamoDB（9.C1）、Google 自家用 Spanner（9.C10）一樣 — 雲商旗艦 DB 都會用在自家旗艦產品。讀此類 dogfood 案例的權重應該高、因為「雲商自己賭身家」。

需要警惕：

• 案例 沒有 提具體 throughput、latency、cost 數字。Microsoft 內部數字通常不公開、跟 AWS / GCP 案例的數字密度差很多。
• 「MongoDB 不夠用」是行銷話術。實際是 MongoDB 在某些 workload pattern 下不夠用、不是普遍結論。

策略

可重用的工程做法：

1. MongoDB-compatible Cosmos DB 是大規模遷移的捷徑：應用層改動少、底層擴展性升級。但要驗證 特定 query pattern 在兩邊行為一致。對應 01.3 schema migration rollout evidence 的 dual-write 驗證。
2. 分析平台用 weakest acceptable consistency：session consistency 或 eventual consistency 通常夠用、能換到 3-10x throughput。對應 01.5 transaction boundary 的一致性取捨。
3. dogfood 是 vendor selection 的重要訊號：vendor 自家是否用在 production-critical workload、能告訴你「他們對自己服務的信任度」。
4. Multi-model 是 Cosmos DB 的差異化價值：同一個服務可以用 SQL API / MongoDB API / Cassandra API / Gremlin / Table API、避免多個 DB 服務並存。

跨平台等效：AWS DynamoDB（KV）+ DocumentDB（MongoDB-compatible）、GCP Firestore（document）+ Spanner（SQL）+ Bigtable（KV）— 各家用不同產品覆蓋 multi-model、Cosmos DB 是少數「單一產品支援多 model」。

下一步路由

• 對照其他 Cosmos DB 案例 → 9.C11 Minecraft Earth / 9.C21 ASOS Black Friday
• 對照其他 dogfood 案例 → 9.C1 AWS Prime Day / 9.C10 Spanner
• 想做 MongoDB-compatible 遷移 → 01.4 database migration playbook
• 想理解 multi-model 取捨 → 01 資料庫模組 + 00 服務選型模組
• 想對比 Cosmos DB MongoDB API vs SQL API 的選型 → Cosmos DB MongoDB API vs SQL API
• 想做 RU 成本模型與容量 sizing → Cosmos DB RU 成本模型

引用源

• Microsoft 365 boosts usage analytics with Azure Cosmos DB
• A technical overview of Azure Cosmos DB

觀察

Mercado Libre 在 GCP 的關鍵敘述（引自 Mercado Libre Customer Story）：

關鍵能力：「Vertex AI Search across 150 million items in three pilot countries that is helping its 100 million customers find the products they love faster」、「BigQuery to design a robust data architecture that ensures the availability of data in near real-time」。

判讀

Mercado Libre 揭露三個區域電商容量規劃重點。

1. 區域電商 ≠ 全球電商：拉丁美洲 18 個國家、各自有獨立貨幣、稅務、物流、合規規則。容量規劃單位通常是「per country」、不是「per region」。對應 9.C14 Standard Chartered 的市場分割、跟 9.C17 BookMyShow 的跨國平台對照。
2. Vertex AI Search = 「搜尋」當作 ML 服務、不是 Elasticsearch：傳統電商搜尋靠 Elasticsearch / OpenSearch + 自訓 ranker、Mercado Libre 用 vendor managed Vertex AI Search、把「商品搜尋 + 推薦排序」當作 ML 黑盒。這個取捨用「不可調參」換「快速上線」。對應 00 服務選型模組 的 build vs buy、跟 9.C9 Spotify 的 managed 轉向同類思維。
3. 「數百萬美金 incremental revenue」是 ML 容量規劃的真實 ROI：搜尋改善 → 轉換率 → 訂單 → 收入、ML 投資的 cost 才能合理化。容量規劃不只看「能撐多大流量」、也要看「擴容能否帶業務 ROI」。對應 9.7 成本邊界與 efficiency 的成本工程化。

需要警惕：

• 「1.5 億商品 in 3 pilot countries」是 試點規模、不是全平台。全平台商品總數應該更大、但案例沒揭露。
• BigQuery「near real-time」沒指明 latency（秒級、分鐘級）。BigQuery 傳統是 minutes-level、不是 sub-second、對「即時」的定義要謹慎。

策略

可重用的工程做法：

1. 區域電商的容量規劃是「per country × peak_factor」：不是「per region」聚合、要按國家分別規劃。每個國家自己的 Black Friday / Cyber Monday / 雙 11 / 6.18 等本地大促時間都不同。對應 9.6 容量規劃模型。
2. 「商品搜尋」適合用 managed AI search：除非有自家強大的 ML team + 大量訓練資料、否則 Vertex AI Search / OpenSearch Service 等 managed 比自建 ranker 划算。
3. BigQuery 是 LatAm / 新興市場數據平台的標配：能處理 PB 級資料、無需 cluster 管理、適合中等工程資源的團隊。對應 04 可觀測性模組 的 data 平台選型、跟 9.C17 BookMyShow 的 Redshift + Athena 對照。
4. ML ROI 直接 ＝ 業務指標：transaction conversion rate、AOV、recommendation CTR 都是 ML 容量規劃的下游 KPI。

跨平台等效：AWS Personalize + Redshift + Glue、Azure AI Search + Synapse 都是對等候選。差異是 vendor 整合度跟模型的可調參空間。

下一步路由

• 對照其他大規模電商 → 9.C21 ASOS Black Friday / 9.C22 Wayfair burst
• 想規劃跨國容量 → 9.C14 Standard Chartered + 9.C17 BookMyShow
• 想做 ML feature serving → 9.C25 Tubi ML feature store
• 想做 build vs buy 決策 → 00 服務選型模組 + 9.7 成本邊界與 efficiency

引用源

• Mercado Libre Customer Story
• How Mercado Libre uses real-time analytics for on-time delivery