想像你正在為一家剛起步的精品咖啡店建立線上商城。老闆興奮地告訴你：「我們只有50種商品，每月大約1000筆訂單，預算有限但希望未來能擴展到全國。」這個看似簡單的需求，背後隱藏著電商系統設計的核心挑戰：如何在有限資源下建立一個既能快速上線，又保留未來擴展彈性的系統？
電商系統的複雜度常被低估。表面上只是「選商品、加購物車、結帳」三個步驟，但深入探究會發現每個環節都充滿技術決策：購物車資料該存在哪裡？如何處理並發下單導致的庫存超賣？支付失敗時如何確保資料一致性？
這些問題的答案，決定了系統能否從每天10筆訂單順利成長到每秒1000筆。今天，我們將從一個真實的角度出發，探討如何設計一個務實的電商系統。不追求過度工程，而是在適當的時機做出適當的架構決策。
我們要設計的是一個B2C電商平台，初期服務單一品牌的線上銷售。這個系統不只是展示商品的櫥窗，更是連接品牌與消費者的數位橋樑。系統必須提供流暢的購物體驗，從商品瀏覽、選購到支付，每個環節都影響著轉換率。
因此，系統設計的核心價值在於確保交易的安全性與可靠性的同時，降低購物車放棄率，提升轉換率。
技術挑戰 1：購物車狀態管理的複雜性
購物車看似簡單，實則涉及多重技術考量。當用戶在手機上瀏覽商品，加入購物車後改用電腦結帳，系統如何確保購物車內容同步？訪客轉換為會員時，如何合併購物車？這些場景直接影響用戶體驗與轉換率。
技術挑戰 2：庫存管理與並發控制
假設只剩最後一件限量商品，10個用戶同時點擊購買，系統如何確保不超賣？如何在保證資料一致性的同時，維持良好的用戶體驗？這個問題在促銷活動時尤其關鍵。
技術挑戰 3：支付整合與交易一致性
支付是電商系統最關鍵也最複雜的環節。當支付系統 timeout，我們無法確定交易是否成功時，該如何處理？如何確保「扣款」與「訂單成立」的原子性？
| 單體架構 | 微服務架構 | 模組化單體 | |
|---|---|---|---|
| 核心特點 | 所有功能在單一應用中 | 功能拆分為獨立服務 | 單一部署但內部模組化 |
| 優勢 | 開發簡單、部署容易、除錯方便、無網路延遲 | 獨立擴展、技術多樣性、故障隔離 | 保持簡單性、易於重構、未來可拆分 |
| 劣勢 | 擴展困難、技術綁定、部署風險高 | 複雜度高、網路開銷、資料一致性挑戰 | 需要良好的模組設計、仍有部署耦合 |
| 適用場景 | 小型團隊、快速驗證、預算有限 | 大型團隊、高流量、複雜業務 | 中型團隊、成長中的業務 |
| 複雜度 | 低 | 高 | 中 |
基於小團隊、預算有限、需要未來擴展性等條件，模組化單體架構是最佳選擇。
這個決策參考了Shopify的成功經驗：他們用模組化的Rails單體應用處理每分鐘2.84億次請求。關鍵在於從一開始就設計清晰的模組邊界，為未來的服務拆分預留空間。細節可參考下方業界案例
架構重點：
系統架構圖：
為什麼這樣設計：
這個階段的關鍵是建立穩固的資料模型基礎。例如以下核心資料表設計：
// 商品資料模型範例（示意用途）
interface Product {
id: string
name: string
slug: string // URL友善的唯一識別
basePrice: Decimal
status: 'active' | 'inactive' | 'outOfStock'
}
interface ProductVariant {
id: string
productId: string
sku: string // 庫存單位
attributes: Record<string, any> // {size: 'L', color: 'red'}
price: Decimal
inventory: number
reserved: number // 購物車預留數量
}
interface CartItem {
userId?: string // 可為null（訪客）
sessionId: string
variantId: string
quantity: number
addedAt: Date
expiresAt: Date // 購物車項目過期時間
}
架構演進重點：
關鍵設計變更：
購物車優化策略
庫存管理改進
企業級架構特點：
這個階段開始考慮服務拆分，但採用漸進式的 Strangler Fig Pattern：
| 技術選項 | 優勢 | 劣勢 | 適用場景 |
|---|---|---|---|
| 後端框架 | |||
| Next.js | 前後端同源，支持靜態生成與伺服器端渲染(SSR)，開發效率高，內建API Route，簡化後端開發 | 大型複雜後端邏輯不適合，只適合輕量API，伺服器資源消耗較高 | 電商前台、行銷頁、具SEO需求的網頁、輕量API服務 |
| Node.js + Express | 統一前後端語言、豐富生態系、快速開發 | CPU密集運算較弱 | 中小型電商、即時功能需求 |
| Java Spring Boot | 成熟穩定、企業級支援、強類型系統 | 學習曲線陡峭、開發速度較慢 | 大型企業、複雜業務邏輯 |
| Python Django | 快速開發、豐富套件、優秀ORM | 效能較低、GIL限制 | 內容為主的電商、快速原型 |
| 資料庫選擇 | |||
| PostgreSQL | ACID合規、JSON支援、複雜查詢 | 水平擴展困難 | 交易資料、商品目錄 |
| MongoDB | 彈性schema、水平擴展、高效能 | 缺乏ACID、JOIN複雜 | 商品評論、用戶行為數據 |
| 快取方案 | |||
| Redis | 毫秒級延遲、豐富資料結構、持久化選項 | 記憶體成本高、單執行緒限制 | Session、購物車、熱點數據 |
| Memcached | 極簡高效、多執行緒 | 功能單一、無持久化 | 純快取場景 |
過早優化陷阱
購物車狀態管理錯誤
庫存超賣問題
Shopify的模組化單體成功：
參考: Shopify Engineering - Deconstructing the Monolith
參考: ByteByteGo - Shopify Tech Stack
初期（2006-2010）
成長期（2010-2018）
近期狀態（2019-2025）
技術指標：
業務指標：
針對今日探討的簡易電商系統設計，建議可從以下關鍵字或概念深化研究與實踐：
Event Sourcing與CQRS：透過事件溯源模式，可以完整記錄系統狀態變化，特別適合需要審計追蹤的電商場景。深入了解這個模式能幫助設計更靈活的訂單處理系統。
Saga Pattern：這是處理分散式交易的關鍵模式，學習如何在沒有分散式交易的情況下保證資料最終一致性，對於未來系統服務化極為重要。
Multi-tenant Architecture：探索如何設計支援多商家的電商平台架構，了解資料隔離、客製化、資源分配等挑戰的解決方案。
Headless Commerce：研究前後端分離的電商架構，了解如何通過API驅動的方式支援多管道銷售（網站、App、社交媒體、IoT設備等）。
Core Web Vitals優化：深入學習Google的網站體驗核心指標，掌握提升LCP、INP、CLS的具體技術，這直接影響SEO排名與轉換率。
可根據自身興趣，針對上述關鍵字搜尋最新技術文章、專業書籍或參加線上課程，逐步累積專業知識和實踐經驗。
明天我們將進入第二週的學習旅程，探討「社交媒體動態牆系統」的設計。相比今天的電商系統著重於交易的準確性，社交系統更強調即時性與個人化。我們將深入探討動態排序演算法、內容推薦機制，以及如何處理每秒數萬則動態更新的技術挑戰。
從購物車到動態牆，看似完全不同的系統，背後卻有著相似的架構智慧：如何在有限資源下，為用戶提供最好的體驗。期待與你一起探索社交系統背後的技術奧秘！
iThome鐵人賽
看影片追技術