前言

當我們談到 Amazon 類型的超大型電商平台時，很多人第一時間想到的是首頁很快、商品很多、促銷很多、訂單很多，但站在系統設計的角度，真正困難的從來不是單一頁面怎麼 render 出來，而是整個平台要同時承接極高的讀流量、複雜的交易鏈路、龐大的商品資料、跨區域部署、高峰活動壓力與長尾的一致性問題。

換句話說，電商系統不是「一個網站加一個資料庫」，而是一組責任不同、流量型態不同、擴展方式也不同的系統群。首頁、搜尋、商品頁、購物車、庫存、訂單、支付、履約、客服、通知、推薦、報表，看起來都屬於同一個平台，但它們對延遲、一致性、可用性與資料模型的要求其實完全不一樣。

本系列會以 Amazon 類型的超大型電商作為抽象案例，重點不是猜測某一家公司的私有實作，而是理解在公開常識與業界常見架構下，一個真正高流量、高資料量、高營運複雜度的電商平台，通常會遇到哪些典型問題，以及為什麼系統會逐步長成今天這種分層且分工明確的形態。

系列文章導航

  1. 從商品瀏覽到訂單履約，超大型電商平台到底怎麼拆（本篇）
  2. 商品目錄、搜尋、推薦、快取與 CDN，為什麼電商本質上是讀流量主導的系統
  3. 購物車、庫存預留、下單流程與超賣治理
  4. 支付、退款、帳務、對帳與交易一致性
  5. MySQL、PostgreSQL、DynamoDB、Redis、OpenSearch 與 S3，資料到底該放哪裡
  6. CloudFront、WAF、ALB、EKS、Aurora 與 Multi-Region，AWS 基礎設施如何規劃
  7. 黑五與大促場景下的限流、降級、觀測、災難復原與成本控制

為什麼超大型電商比一般網站複雜得多

很多工程師第一次碰到電商平台時，會把它想像成「有商品、有購物車、有下單功能的 Web 服務」。這種理解不能說錯，但對超大型電商來說太粗糙了。

因為電商平台同時包含至少四種完全不同的系統問題：

  1. 超高讀流量問題：首頁、活動頁、商品頁、搜尋結果頁、推薦區塊，會承接遠高於下單流量的請求量。
  2. 高價值交易問題：購物車、庫存、訂單、支付、退款，要求資料正確、狀態清晰、可追蹤、可補償。
  3. 長鏈路協調問題：下單之後不只付款，還有撿貨、包裝、出貨、通知、客服、發票、退貨、退款與對帳。
  4. 平台治理問題：高可用、觀測、限流、權限、成本、資料歸檔、多區域部署，全部都得進入考量。

所以一個成熟的電商平台，核心工作不是把所有功能塞進一套應用，而是先釐清責任邊界，再決定哪些鏈路要同步，哪些鏈路應該事件化，哪些資料需要強一致，哪些資料只要近即時或最終一致即可。

先建立全局地圖：大型電商平台通常有哪些核心子系統

先看一個簡化的電商平台分層圖：

flowchart LR
    U[使用者 App / Web] --> G[CDN / API Gateway / WAF]
    G --> FE[Frontend / BFF]
    FE --> CAT[Catalog]
    FE --> SRH[Search]
    FE --> REC[Recommendation]
    FE --> CRT[Cart]
    FE --> ORD[Order]
    ORD --> INV[Inventory]
    ORD --> PAY[Payment]
    ORD --> FUL[Fulfillment]
    ORD --> NOTI[Notification]
    CAT --> IDX[Search Index]
    CAT --> CACHE[Redis / CDN Cache]
    ORD --> MQ[MQ / Event Bus]
    PAY --> MQ
    INV --> MQ
    FUL --> MQ
    MQ --> BI[Analytics / Reporting / Audit]

這張圖的重點不是「服務要拆這麼多個」，而是讓你先看到幾個重要現實：

  • Catalog 與 Search 看起來都在處理商品，但一個偏主資料管理，一個偏查詢與索引。
  • Cart 不等於 Order，因為購物車通常代表使用者意圖，而不是正式交易承諾。
  • Inventory 不能只是商品模組裡的一個欄位，因為真正的庫存管理往往牽涉倉庫、可售量、預留量、退貨與盤點。
  • Payment 與 Order 高度相關，但狀態機不同，不能簡單混成一個欄位。
  • Fulfillment 是訂單後半段的世界，它面對的是倉儲與物流，而不是前台瀏覽流量。

如果一開始就把這些責任混在一起，系統後面一定會在資料耦合、部署風險與擴展成本上付出代價。

四種最常見的流量型態

大型電商不是只有「流量很大」，而是不同型態的流量同時存在，且彼此不能互相拖垮。

1. 首頁、活動頁與商品頁的瀏覽流量

這類流量通常最大，而且有很高比例可以透過 CDN、頁面快取、邊緣快取與應用層快取吸收。它的挑戰不是交易一致性，而是：

  • 如何降低 origin 壓力
  • 如何處理促銷更新與快取失效
  • 如何保證熱門商品頁在活動期間仍然穩定

2. 搜尋與篩選流量

搜尋看起來只是查資料，但實際上通常會有：

  • 關鍵字全文搜尋
  • 分類與屬性過濾
  • 排序與聚合
  • 推薦與個人化權重

這類查詢如果硬塞到交易資料庫，很快就會拖垮主線系統。所以大型電商幾乎一定會把這部分外移到專門的搜尋索引體系。

3. 下單與支付交易流量

這部分流量未必最大，但價值最高。因為它一旦出錯，影響的不只是使用者體驗，而是直接變成錯單、超賣、少扣款、重複扣款、退款異常與客服工單。

這條鏈路最關心的是：

  • 訂單是否重複建立
  • 庫存是否正確預留
  • 支付狀態是否可追蹤
  • 異常時能否補償與對帳

4. 營運、履約與報表流量

後台營運經常被低估，但對超大型電商來說，商家後台、客服查詢、營運報表、物流整合、結算對帳這些工作負載，一旦跟線上交易共用同一套讀寫路徑，很容易互相干擾。

所以成熟系統通常會把這類需求往：

  • 查詢投影資料庫
  • Data warehouse / data lake
  • 離線報表與批次處理

等方向分流，而不讓後台分析查詢直接衝撞交易主庫。

同步與非同步的責任邊界

大型電商的其中一個核心能力，是知道什麼事情應該同步完成，什麼事情應該延後處理。

以「使用者成功下單」為例，常見同步主線通常包含：

  1. 驗證商品與價格快照。
  2. 驗證促銷資格。
  3. 驗證或預留庫存。
  4. 建立訂單。
  5. 建立支付意圖或進入支付流程。

而以下工作往往適合非同步處理：

  • 發送 Email 或推播通知
  • 寫入行為事件與分析資料
  • 更新推薦特徵
  • 同步到 CRM 或行銷系統
  • 更新較慢的查詢投影

這種邊界畫不清楚，系統會出現兩種典型問題：

  • 主流程做太多事，導致延遲飆高、失敗面積過大。
  • 主流程做太少事，導致真正關鍵的狀態沒有被安全地確認。

對架構師來說，這不是語法問題，而是交易邊界與責任切分問題。

為什麼不能一開始就用「全面微服務」思考

很多人在談大型電商時，會自動把答案指向微服務。但這其實只是一種部署與團隊協作形式，不是架構正確性的保證。

對超大型電商來說，真正重要的是先回答以下問題：

  • 哪些資料是誰擁有的
  • 哪些狀態可以延遲同步
  • 哪些流程一定要有強約束
  • 哪些服務真的有獨立擴展價值
  • 哪些查詢只是 projection，不應該反過來成為真實來源

如果這些問題還沒想清楚，就算拆成二十個服務，也只是把單體裡的混亂邏輯搬到網路上。你會得到更多 RPC、更多 timeout、更多重試、更多部署風險，但不一定得到更好的平台。

實務上更合理的順序通常是：

  1. 先把 domain boundary 切清楚。
  2. 先把讀流量與交易流量分開處理。
  3. 先把資料 ownership 想清楚。
  4. 真正有明顯獨立 scaling 需求時，再拆成可獨立部署的服務。

以業務能力而不是以資料表切系統

大型電商很容易犯的一個錯，是用資料表或頁面功能去切系統，例如：

  • 商品一個服務
  • 訂單一個服務
  • 訂單明細一個服務
  • 支付紀錄一個服務

這種切法通常沒有抓到真正的邏輯邊界，最後會讓一個簡單業務流程需要跨很多服務來回呼叫。

更合理的方式通常是從業務責任切起：

  • Catalog 負責商品主資料與上架管理。
  • Search 負責商品搜尋與查詢最佳化。
  • Cart 負責暫存選購狀態。
  • Order 負責訂單生命週期。
  • Inventory 負責預留、扣減、回補與盤點。
  • Payment 負責金流整合與支付狀態追蹤。
  • Fulfillment 負責倉儲與物流執行。

這樣做的好處是：資料 ownership 比較清楚，團隊責任也比較清楚，未來要做事件驅動、資料投影、查詢分流時，模型比較不容易混亂。

2026 年看超大型電商架構，真正要關心的是什麼

到了 2026 年，大家對 microservices、event-driven、serverless、multi-region 這些詞都已經不陌生。真正有價值的已經不是背名詞，而是知道什麼時候該用、為什麼用、用了之後要付出什麼代價。

對超大型電商來說，真正重要的其實是這四件事：

  1. 讓前台高流量查詢與後台高價值交易分開治理。
  2. 讓庫存、訂單、支付這些強狀態鏈路可以被追蹤、補償與對帳。
  3. 讓資料層依 workload 分工，而不是把所有責任壓在單一資料庫。
  4. 讓 AWS 基礎設施、可觀測性、限流與成本治理從 Day 1 就進入架構思考。

這也是本系列後面六篇會逐步展開的主線。

總結

超大型電商的難點，不在於單一技術元件有多炫，而在於它必須同時處理高讀流量、高交易價值、跨系統協調與平台治理這四種本質完全不同的問題。

所以從架構視角來看，第一步從來不是選 MySQL 還是 PostgreSQL，也不是先決定要不要用 Kubernetes，而是先回答：平台有哪些核心能力、哪些能力彼此應該隔離、哪些鏈路需要強一致、哪些資料只需要被快速查到。

一旦這張地圖建立起來，後面的搜尋架構、庫存預留、支付帳務、資料層分工與 AWS 規劃，才會有明確方向。