觀察

拓元 Tixcraft 在 AWS 的關鍵數字（引自 tixCraft Case Study 與 AWS re:Invent 2015 簡報）：

服務組合（依用戶提供的架構圖）：

• 入口：Amazon Route 53（DNS）+ CloudFront + S3（靜態資源 static.tixcraft.com）
• UI 層：Elastic Load Balancing → EC2 跨 3 個 Availability Zone（Tixcraft UI）
• API 層：ELB → EC2 跨 3 個 AZ（API）+ ElastiCache 加速 session
• 資料層：DynamoDB 作為主要寫入目標（接 UI 寫入跟 API 寫入）
• 付款層：獨立的 EC2 Payment、連到 traditional server（合作金流、跑於企業 data center）
• 同步層：S3 Sync + EC2 Bridge 跟 corporate data center 的 backend 雙向同步

判讀

拓元案例最值得讀的、是它揭露三個 flash-sale 工程設計的非直覺事實。

1. DynamoDB 作為寫入緩衝、不是 OLTP：搶票時的「訂單」先丟進 DynamoDB、傳統 server 用自己能承受的速度消費、即時生效在此架構下不是目標。架構上 DynamoDB 扮演 durable queue 的角色、不是傳統 OLTP DB。這層解耦讓「前端可以擴 130 倍、後端不用同步擴」、避免後端被前端拖垮。對應 03 訊息佇列模組 的 outbox / async delivery 概念、跟 01 資料庫模組 的 transaction boundary 分離。
2. DynamoDB IOPS 從 20 衝到 135,000 = partition 設計能撐：這個 6,750 倍的彈性不是 DynamoDB 魔法、是 partition key 設計均勻 的結果。partition key 不均、IOPS 上限是「最熱 partition 上限」、不是「總和」。對應 9.C5 Amazon Ads 的同一判讀重點、跟 9.4 Saturation Discovery 的 hot partition 識別。
3. 30 分鐘擴 130 倍 = 雲原生架構的存在證明：6 台 → 800 台不是手動操作、是 Auto Scaling Group + AMI prebuild + load balancer warmup 的組合。傳統 IDC 做不到。這層彈性是「30 秒內」flash-sale 的前置條件。對應 05 部署平台模組 的 autoscaling 與 9.6 容量規劃模型。

需要警惕的判讀盲點：

• 「限流到底怎麼做」這個工程社群關心的問題、架構圖上看不到明確元件。可能是「DynamoDB 寫入排隊 = 隱性限流」、也可能是 ELB / WAF / 應用層限流。沒有公開資訊不要過度推測。
• 2015 年的數字、用的還是 t2.micro 跟舊版 DynamoDB throughput model。現在等效實作可能會用 DynamoDB on-demand、AWS WAF、CloudFront WAF rules、或 SeatGeek-style Virtual Waiting Room（見 9.C16）。
• 「30,000 張 / 3 分鐘」是 票房成績、不是 系統極限。系統能撐遠不止這個量、只是票本身賣完了。

策略

可重用的工程做法：

1. flash-sale 的核心架構模式：寫入緩衝 + 慢速消費：前端把訂單塞進可彈性擴容的儲存（DynamoDB / Redis Stream / Kafka）、後端按自己能力消費。這個模式讓「短時間吸收洪峰」跟「實際處理」解耦。對應 03 訊息佇列模組 與 01 資料庫模組。
2. partition key 設計是 flash-sale 的命脈：搶票場景天然容易 hot partition（同一場演唱會 = 同一 event_id）、必須用 composite key（event_id + user_id_hash）或 write sharding（event_id + random_suffix）分散。對應 9.C5 Amazon Ads。
3. flash-sale 必須事先 ELB / Auto Scaling 預熱：開賣前 30-60 分鐘 pre-warm ELB、預先啟動最低額度的 EC2、避免 t=0 時冷啟動。對應 AWS 官方 Flash Sale 工程指引。
4. 付款層獨立、不被搶票流量影響：拓元把 Payment EC2 拉出來、直連傳統金流 server。讓「選位 + 下單」的高頻流量不會塞爆「付款」的低頻流量。對應 9.5 瓶頸定位流程 的關鍵路徑切分。
5. 限流（rate limiting）通常是隱性的、不一定看得到 component：DynamoDB 寫入排隊本身就是隱性限流；也可以加 WAF rate-based rule、ELB request throttling、或前置 Virtual Waiting Room 做明確限流（見 9.C16）。

跨平台等效：GCP Cloud Spanner / Bigtable + Cloud Pub/Sub 作 buffer + GKE autoscaling；Azure Cosmos DB + Service Bus + AKS；自建 PostgreSQL + Kafka + Kubernetes 都可以實作對等架構。差異是 vendor 整合度跟擴容速度。

下一步路由

• 想設計 flash-sale 緩衝架構 → 03 訊息佇列模組 + 01 資料庫模組 + 9.6 容量規劃模型
• 想做 partition key 設計 → 9.C5 Amazon Ads + 01.6 高併發資料存取
• 想做明確限流 / 排隊機制 → 9.C16 SeatGeek Virtual Waiting Room
• 想預熱 ELB / Auto Scaling → 05 部署平台模組 + 9.11 高峰事件準備
• 對照其他售票市場 → 9.C17 BookMyShow（印度市場、年售 2 億張）
• 想理解 flash-sale 場景的 partition key 反模式 → DynamoDB partition key 反模式
• 想評估 on-demand vs provisioned 在 flash-sale 的搭配 → DynamoDB on-demand vs provisioned

引用源

• tixCraft Case Study (AWS)
• tixCraft on AWS re:Invent 2015 Recap (SlideShare)
• tixCraft: Handling Millions of Ticketing Requests with AWS (YouTube)
• Top considerations for Flash sale events (AWS Cloud Operations Blog)
• Handle traffic spikes with Amazon DynamoDB provisioned capacity

觀察

SeatGeek Virtual Waiting Room 架構（引自 AWS Architecture Blog）：

業務動機：取代「第三方 waiting room 服務」、原因是缺乏客製化（VIP 規則、優先級）跟 metrics 可見度。

關鍵機制：

1. Token = 庫存單位：access token 總數 = 可售票數量。沒拿到 token 的用戶被導到 waiting room 頁面、看到排隊位置與預估等待時間。
2. FIFO 或 priority queue：可以按進入順序、也可以對 VIP 客戶優先發 token。
3. Token 失效機制：用戶完成購票 / 主動退出時、token 釋放回 pool、給下一位等候用戶。

判讀

SeatGeek 案例揭露三個明確限流設計重點。

1. 隱性緩衝 vs 明確排隊是兩種架構取捨：Tixcraft 模式「全部塞進 DynamoDB」、用戶以為下單成功、實際處理排隊。SeatGeek 模式「明確告訴你排隊位置」、用戶看得到等待時間。前者犧牲透明度換流量吸收、後者犧牲流量吸收換體驗。對應 9.10 Production-Side 驗證 的用戶體驗 vs 系統行為取捨。
2. WebSocket connection 是 stateful 容量單位：100 萬個 active waiting room 用戶 = 100 萬個 WebSocket connection、每個 connection 都吃記憶體跟 file descriptor。Lambda 沒辦法保持 WebSocket、需要 API Gateway WebSocket API 或 AppSync 配合。對應 05 部署平台模組 的 stateful service 容量規劃。
3. 限流粒度 = 業務粒度：「每分鐘發 N 個 token」這個參數直接決定「每分鐘成交 N 張票」。N 太小、賣不完；N 太大、後端撐不住。N 不是技術參數、是業務 × 後端容量的協商結果。對應 9.6 容量規劃模型 把容量規劃跟業務 KPI 對接。

需要警惕的判讀盲點：

• AWS Architecture Blog 沒提具體流量數字（concurrent users、queue depth、throughput）。讀者無法直接套用到自家容量規劃、必須自己壓測。
• DynamoDB 4 張表的設計 看似簡單、實際上每張表的 partition key / sort key 設計都要仔細想。複製這個架構不等於拿到 SeatGeek 的吞吐能力。
• 「token expiration」機制如果設計不好（例如用戶關閉瀏覽器、token 沒回收）、會導致「排隊很長但實際空著」、影響轉換率。

策略

可重用的工程做法：

1. 明確 vs 隱性限流的選擇：高價值門票（演唱會、限量周邊）適合明確排隊（用戶願意等）；高頻低價值商品（FCFS 折扣）適合隱性緩衝（讓用戶快速完成）。
2. Virtual Waiting Room 是 stateful service、要規劃連線容量：不是 stateless Lambda 一招到底、需要 WebSocket gateway + DynamoDB state store。對應 05 部署平台模組 的混合架構。
3. token 過期策略要寫進設計初稿：用戶離開、付款超時、瀏覽器當掉 — 三種狀況的 token 回收邏輯都不一樣、要明確設計。
4. 可觀測性是「自建 waiting room」勝過「第三方」的關鍵：SeatGeek 換掉第三方就是要 metrics 可見、知道每分鐘 token issue rate、queue depth distribution、token expiration rate、conversion funnel。對應 04 可觀測性模組。

跨平台等效：GCP Cloud Functions + Firestore + Pub/Sub；Azure Functions + Cosmos DB + SignalR；自建 Redis（INCR / TTL）+ WebSocket gateway（Soketi / Socket.IO + Redis adapter）都可以實作對等架構。AWS 還推出官方 Virtual Waiting Room on AWS Solutions、是 SeatGeek 模式的可重用版本。

下一步路由

• 想設計明確排隊限流 → 05 部署平台模組 + 9.11 高峰事件準備
• 對照隱性緩衝模式 → 9.C15 Tixcraft
• 想做 conversion funnel 可觀測性 → 04 可觀測性模組 + 04.16 SLI / SLO 訊號
• 想了解 stateful service 容量規劃 → 05 部署平台模組 + 9.5 瓶頸定位流程

引用源

• Build a Virtual Waiting Room with Amazon DynamoDB and AWS Lambda at SeatGeek
• Virtual Waiting Room on AWS (Solutions)
• How to manage peak traffic on AWS using Queue-it’s virtual waiting room

觀察

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