中秋節

多數人把中秋節當成烤肉、月餅與返鄉列車的節日；但對軟體工程師而言，中秋節是一場可重複的混沌工程。電商平台瞬間湧入的禮盒訂單、物流系統的冷鏈追蹤、行銷簡訊的併發推播、支付閘道的庫存競爭，全都會在這個節日前後被拉到極限。

在我們監控的生產環境中，中秋節前 72 小時的訂單峰值，往往比雙十一更難預測，因為它混合了家庭送禮與企業採購的雙重流量型態。

本文不談文化習俗，而是拆解中秋節背後被忽略的技術系統：電商流量、物流冷鏈、農曆演算法、推播系統、支付一致性、SRE 觀測性與 AI 需求預測。這是給資深工程師的節日系統復盤，不是節日散文。

中秋節的數位化前台：電商平台如何承接瞬時流量

中秋節的電商流量不是平滑上升，而是集中在節前一到兩週的夜間。我們在一個綜合電商平台觀察到，中秋節前 14 天開始，月餅、茶葉與酒類商品的搜尋量每天以 18% 到 23% 的速度增長；但真正致命的不是搜尋，而是購物車到結帳的轉換。消費者在深夜時段大量送出禮盒訂單，形成 21:00 到 23:00 的尖峰。若把平常日間的 QPS 當基準，這個夜間峰值可以放大到 7 到 10 倍。

後端系統需要先解決的不是伺服器數量，而是資源自動擴容的觸發延遲。Kubernetes 的 Horizontal Pod Autoscaler（HPA）預設以 15 秒抓取 metrics，但從 Pod 建立到服務真正接收流量還需要 30 秒到 90 秒。中秋節期間只靠 HPA 的 reactive scaling 會讓使用者在結帳頁看到 502。更穩妥的做法是搭配 keda 這類 event-driven autoscaler，用 RabbitMQ queue depth 或 Redis stream lag 直接觸發擴容，而不是等 CPU 飆高。我們曾在一次中秋節檔期把擴容觸發改成 queue-based，P95 延遲從 2. 4 秒降到 680 毫秒。

流量治理還需要把「送禮」與「自用」拆成兩種路徑。送禮訂單通常有指定送達時間、多地址與客製賀卡，這些都是長尾操作；自用購買則偏向快速結帳。用 API gateway 的 routing rules 把兩類流量導向不同服務池，可以避免長尾操作拖垮核心下單服務。延伸閱讀：電商大促的 CDN 預暖策略

月餅供應鏈的資料工程挑戰：從原料溯源到冷鏈監控

中秋節對月餅供應鏈的壓力不在生產，而在時間窗。一顆蛋黃酥從烤好到消費者手上，最佳賞味期通常只有 5 到 7 天。企業大批訂購的中秋節禮盒又往往集中在同一週出貨，導致冷鏈物流的揀貨、包裝、宅配系統全部卡在同一個週末。

我們在一個食品供應鏈專案中導入 MQTT 溫度感測器，每 30 秒上傳一次冷藏車廂溫度。真正的困難不是收集資料，而是定義「失溫事件」的邊界。若把閾值設在 4°C，高速公路開門卸貨時的短暫升溫會產生大量 false positive；若設在 8°C，又會漏掉實際影響品質的緩慢升溫。後來我們用 Apache Flink 做 session window，連續 5 分鐘超過 6°C 才觸發警報，準確率提升到 94%。

這條資料管線還需要跟訂單系統對齊。每一張中秋節禮盒訂單都應該帶有 lot_id，從生產批次、冷藏車趟次到最後一哩配送全部關聯。沒有這層資料血統，消費者回報月餅變質時，客服只能退錢，無法快速回收同批問題商品。資料工程師在中秋節的價值，就是把「好吃」變成可追蹤的資料契約。

農曆日期計算的程式碼陷阱：中秋節為何每年在國曆漂移

中秋節是農曆八月十五，但國曆日期每年不同。對工程師