The brief
A membership business running retail, wholesale and online courses as three separate operations, with prices and perks that differ per region and per tier. Orders lived in spreadsheets and invoicing was manual. They wanted one platform — two domains, China and the US, on one deployment, with room for more markets later.
Requirements → decisions
| Business rule | System decision |
|---|---|
| Retail, wholesale and courses on one platform | One domain model, three storefronts |
| Two domains for CN and US, more markets later | One deployment, markets as configuration |
| Prices differ by region and member tier | Price books keyed by region × tier |
| Tier changes take effect immediately | Tiers are data, not code — no redeploy |
Data flow
Reads go member → CDN → the Next.js app on ECS → RDS for PostgreSQL, where the CDN is Alibaba CDN for the CN domain and Cloudflare for the US one. Writes go through Stripe: the order is only created once the provider confirms, and the webhook handler is idempotent so a retry can never double-count a payment. Product images and course files live in OSS; transactional mail and scheduled jobs run on Mail and Function Compute. Payment state has exactly one source of truth — the provider and the backend, never the browser.
Cloud
Managed where it is commodity, custom where it is the business: one ECS deployment shared by both domains, RDS for PostgreSQL with backups and read replicas, OSS for assets, Mail for transactional email, Function Compute for scheduled and async work, and a CDN in front of each domain — Alibaba CDN for CN, Cloudflare (DNS, WAF, CDN) for US. Both domains hit the same deployment behind it.
Backup and disaster recovery
A nightly RDS dump plus a copy of the OSS assets, kept off the primary instance. The recovery path is written down and rehearsed: restore the dump, point the app at it, re-attach the asset bucket.
Scale
Sized for today — 3,000+ members across two domains on one shared deployment. At 10× the plan is already decided: a new market is configuration rather than a code change; traffic is absorbed by scaling the shared ECS up first and adding instances after; the database grows into read replicas with writes staying on the primary; OSS and both CDNs grow with usage on their own.
In progress
An AI customer support agent, answering member questions against order history, course access and the product catalogue.
專案背景
一個會員制的生意，零售、批發與線上課程原本是三套各自為政的流程，價格和權益又依地區和會員等級不同。訂單靠試算表管理，開立帳務全是人工。他們要的是一個平台——中國與美國兩個網域、共用同一套部署，之後還要能再加新市場。
需求 → 決策
| 商業規則 | 系統決策 |
|---|---|
| 零售、批發、課程要在同一個平台 | 同一套領域模型，三種通路 |
| CN 與 US 是兩個網域，之後還要再加 | 同一套部署，market 用設定切換 |
| 價格依地區與會員等級不同 | 以「地區 × 等級」建立價格表 |
| 等級變更要立即生效 | 等級是資料不是程式碼，不用重新部署 |
資料流
讀取走 會員 → CDN → ECS 上的 Next.js 應用 → RDS for PostgreSQL；CDN 這一段 CN 網域走阿里雲 CDN，US 網域走 Cloudflare。寫入透過 Stripe：金流商確認後才建立訂單，Webhook 處理是冪等的，重送也不會重複計算一筆付款。商品圖與課程檔案放在 OSS，交易信與排程工作分別跑在 Mail 與 Function Compute。付款狀態只有一個真實來源——金流商與後端，不是瀏覽器。
雲端服務
通用的交給託管服務，核心商業邏輯自己寫：一台 ECS 服務兩個網域共用、RDS for PostgreSQL 放關聯式資料並開備份與唯讀副本、OSS 存靜態檔、Mail 發交易信、Function Compute 跑排程與非同步工作；最前面兩個網域各自有 CDN——CN 走阿里雲 CDN，US 走 Cloudflare（DNS、WAF、CDN），後面接的是同一套部署。
備份與災難還原
每日一份 RDS dump，加上 OSS 靜態檔案的備份，都存在主要執行個體之外。還原流程有寫下來也演練過：還原 dump、把應用指過去、重新掛上檔案 bucket。
規模
目前規模是兩個網域、3,000+ 名會員，跑在同一套部署上。放大 10 倍的做法已經先想好：新增市場只是多一組 market 設定，沿用同一套部署；流量先升級共用的 ECS 規格，不夠再加機器；資料庫長成唯讀 replica，寫入仍集中在主庫；OSS 與兩邊的 CDN 本來就隨用量成長。
進行中
AI 客服 Agent：比對訂單紀錄、課程權限與商品目錄，直接回答會員的問題。