前言

很多人在談電商架構時，直覺會把注意力放在訂單與支付，因為那條鏈路最敏感、也最容易出事。但如果從流量占比來看，真正壓力最大的往往不是付款頁，而是首頁、活動頁、商品頁、搜尋頁與推薦區塊。大量使用者每天都在看、比、查、篩選，真正進入下單的人反而是少數。

這也是為什麼超大型電商的第一個架構現實通常不是「交易寫入太多」，而是讀流量先把整個平台打爆。如果商品資料與搜尋查詢沒有分層、快取沒有設計好、索引沒有獨立出去，那麼主資料庫很快就會被大量查詢拖垮，接著連真正重要的交易鏈路都會被連帶影響。

所以這一篇要處理的核心問題是：為什麼超大型電商本質上是讀流量主導的系統？ 以及在這種前提下，商品目錄、搜尋索引、推薦服務、快取與 CDN 應該怎麼分工，才能讓前台流量夠快、夠穩，也不會把交易主線拖下水。

系列文章導航

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

為什麼電商通常是讀多寫少

先建立一個基本直覺：大多數使用者進到電商平台後，第一件事不是下單，而是看東西。

他們會：

  • 看首頁與活動頁
  • 搜尋商品
  • 點進商品頁看規格、評價與圖片
  • 比較不同賣家、不同顏色、不同尺寸
  • 加入收藏、加入購物車，然後離開

這些行為幾乎都是讀取行為，而且很容易在大促期間同時集中到少數熱門商品與熱門關鍵字上。也就是說，電商最常見的第一個瓶頸通常是：

  • 商品查詢太多
  • 搜尋過濾太多
  • 快取命中率不夠
  • 熱門頁面 origin 壓力太高

所以如果平台架構沒有先把讀路徑拆出來，後面即使訂單設計再漂亮，整站也可能在前台流量洪峰時先倒。

商品目錄不只是「一張 products 表」

中小型系統常把商品想成一張 products 表，但大型電商的商品資料往往比這複雜得多。

至少通常會包含：

  • 商品主體資訊：名稱、品牌、分類、描述、圖片、規格
  • SPU 與 SKU 結構：同一商品不同顏色、容量、尺寸、版本
  • 價格資料：原價、售價、會員價、促銷價、地區價
  • 上下架狀態：可售、停售、缺貨、預購
  • 物流屬性：體積、重量、配送限制、倉庫位置
  • 商家屬性：自營、第三方賣家、跨境供應商

光是這些資料本身，就已經很難用單一模型同時滿足後台維護與前台查詢。因為：

  • 後台需要正確、完整、可編輯的主資料。
  • 前台需要的是快速、可搜尋、可排序、可聚合的查詢投影。

這也是為什麼大型電商很少直接拿交易主庫的商品表去做搜尋與複雜篩選。因為那樣做很快就會讓資料模型與查詢模型互相綁死。

搜尋索引為什麼一定要獨立

商品搜尋跟一般 CRUD 查詢最大的不同，在於它需要：

  • 全文搜尋
  • 多欄位排序
  • 多維度過濾
  • Facet 聚合
  • 關鍵字糾錯與同義詞
  • 個人化排序與推薦權重

這些需求如果直接交給 MySQL 或 PostgreSQL 交易主庫，不但成本很高，也很容易干擾真正重要的寫入與交易查詢。所以大型電商幾乎一定會導入獨立的搜尋系統，例如 OpenSearch。

更重要的是，一旦你把搜尋索引視為 query-optimized projection，很多設計會立刻變清楚：

  • 商品主資料的真實來源仍然是 Catalog。
  • 搜尋索引只是查詢投影，不應該反過來成為 authoritative source。
  • 索引同步允許短暫延遲，但需要可觀測與可重建。

商品主資料到搜尋索引的典型資料流

flowchart LR
    OPS[後台商品管理] --> CAT[Catalog Service]
    CAT --> DB[(Catalog DB)]
    CAT --> EVT[ProductChanged Event]
    EVT --> IDXW[Indexer Worker]
    IDXW --> OS[(OpenSearch Index)]
    OS --> API[Search API]
    API --> WEB[Web / App]
    CAT --> CACHE[Redis / CDN Cache]

這條資料流背後有幾個很重要的設計點：

  1. 商品修改通常先進主資料模型，而不是先改搜尋索引。
  2. 搜尋索引同步通常透過事件或背景工作處理，而不是每次同步阻塞後台操作。
  3. 若索引更新失敗，系統需要可重試、可補數、可重建。

這裡的核心觀念是：搜尋快不代表搜尋資料是最真實的，搜尋只是最適合被查的那份資料。

多層快取才是電商前台真正的防線

對超大型電商來說，快取從來不只是加速工具，更是平台穩定性的第一層防線。

常見快取層次包括：

  1. Browser cache：靜態資源、圖片、部分頁面片段。
  2. CDN / Edge cache：首頁、活動頁、商品圖片、可快取的 API 響應。
  3. Application cache：熱門商品詳情、分類頁、部分推薦結果。
  4. Redis cache：商品投影、價格快照、熱門榜、短生命週期查詢結果。

很多架構文章只寫「加 Redis 就好」，但問題從來不是有沒有快取，而是：

  • 哪一層該快取什麼
  • 快取 key 怎麼設計
  • TTL 怎麼設定
  • 商品價格、促銷、庫存變更時如何失效
  • 快取 miss 發生時，系統是否會瞬間打回 origin

快取失效是電商前台最常見的真實難題

電商快取最難的不是把資料放進去，而是知道什麼時候該失效。

以商品頁為例，可能影響快取的事件就包括：

  • 商品名稱或描述修改
  • 圖片更新
  • 價格修改
  • 促銷開始或結束
  • 可售庫存變化
  • 上下架狀態變更
  • 區域價格或幣別調整

如果所有事件都立即全域失效，快取會不穩；如果什麼都不失效，使用者又會看到過時資訊。實務上通常會混合使用：

  • 主動失效
  • 短 TTL
  • 分層更新
  • 背景預熱
  • 局部欄位投影更新

要注意的是，庫存與價格通常是最敏感的兩個欄位，它們往往不能完全依賴長 TTL 的靜態頁面快取，而是需要與更即時的 API 或動態區塊組合。

推薦系統為什麼不能和搜尋混為一談

搜尋與推薦常常一起出現在使用者眼前，但它們在系統上是兩種不同問題。

  • 搜尋偏向使用者明確表達意圖。
  • 推薦偏向系統主動預測使用者可能感興趣的結果。

搜尋更在意索引、關鍵字、過濾、排序與 facet；推薦更在意特徵、行為資料、熱門趨勢與個人化模型。實務上它們會共享部分資料來源，但通常不應該共用完全相同的查詢模型。

大型電商常見做法是：

  • 搜尋結果由搜尋引擎主導。
  • 推薦結果由推薦服務或 ranking service 主導。
  • 前台再用 orchestration 層把結果組合起來。

這樣做的原因很務實：兩種能力的更新頻率、資料新鮮度與排序邏輯都不同，硬湊在一起通常只會讓系統更難維護。

熱門商品與熱門關鍵字怎麼避免把系統打爆

超大型電商最危險的時刻之一，是某個熱門活動、名人帶貨或折扣事件把大量流量集中到少數頁面與少數關鍵字上。

這時候常見的保護策略包括：

  • 熱門商品頁預先快取與預熱
  • 熱門搜尋結果快取
  • 對搜尋 API 做限流與查詢保護
  • 對 expensive query 做 fallback 或降級
  • 圖片與靜態資源全部走 CDN
  • 對推薦結果接受較短時間的不完全即時

真正成熟的設計不是假設每次 query 都會 hit 到 origin，而是預設熱門資料必須被重複使用，而不是被重複計算。

2026 年的電商前台架構，更像資料投影系統而不是資料庫直出系統

到了 2026 年，前台電商架構的一個明顯趨勢，是越來越少直接從交易主資料表拼裝頁面，而是更多依賴：

  • 查詢 projection
  • 搜尋 index
  • 快取層
  • BFF 或 aggregation layer
  • 事件驅動的資料同步

這不是為了追流行，而是因為商品展示、搜尋與推薦天然就更適合被建成查詢最佳化資料面。只要你還把這些能力直接壓在主資料庫上，系統就很難同時做到高吞吐、低延遲與高穩定性。

總結

超大型電商的前台架構，本質上是一套為讀流量最佳化的系統。商品主資料、搜尋索引、推薦結果、快取層與 CDN 必須各自分工，否則平台很快就會在大量瀏覽與搜尋行為下失去穩定性。

所以真正重要的不是「有沒有用 Redis」或「有沒有用 OpenSearch」，而是你是否清楚區分：誰是主資料、誰是查詢投影、誰可以接受延遲、誰必須及時更新、誰應該被快取、誰不應該直接打到交易主庫。

下一篇我們會把視角從讀流量拉回高價值交易鏈路，正式進入電商最敏感的一段：購物車、庫存預留、下單流程與超賣治理。