xDev Asia

分析發送數百萬封電子郵件的問題：實際用例（行銷活動、交易電子郵件、系統警報）。功能性和非功能性需求。粗略估計。比較通知頻道。

設計一個通知系統來發送數百萬封電子郵件

第 1 部分：基礎 — 了解大規模通知問題

亞洲開發網

簡介

想像一下，您是一家擁有 1000 萬用戶的電子商務公司的工程師。每個月，行銷團隊都希望向整個用戶群發送新聞通訊。每次進行閃購時，都需要在幾個小時內發送數百萬封電子郵件。您如何設計系統來處理這個容量？

本課程將幫助您在開始設計之前理解問題。

1. 為什麼電子郵件通知仍然很重要？

電子郵件是第一大溝通管道

指標	電子郵件	推	簡訊
全球用戶	45億	35億	50億
平均開啟率	20-25%	5-8%	95%
每條訊息的費用	0.0001-0.001 美元	免費	0.01-0.05 美元
內容豐富	✅ HTML、圖片	❌ 有限	❌ 僅文字
無需應用程式	✅	❌	✅

實際用例

交易電子郵件（即時、關鍵）：

訂單確認電子郵件
一次性密碼/密碼重置
發票/收據

行銷電子郵件（大量、大容量）：

每週通訊
閃購公告
產品推薦
重新參與活動

系統通知：

向 DevOps 團隊發出警報
預定報告
合規通知

2. 分析需求

功能要求

FR-1: Hệ thống phải gửi được email đến danh sách recipients
FR-2: Hỗ trợ email templates với dynamic content (personalization)
FR-3: Scheduling: gửi ngay hoặc đặt lịch gửi
FR-4: Tracking: open rate, click rate, bounce rate
FR-5: Unsubscribe management (CAN-SPAM compliance)
FR-6: Multi-provider support (failover giữa các ESP)
FR-7: Priority levels: critical > high > normal > low

非功能性需求

NFR-1: Throughput: gửi 10 triệu email trong 4 giờ (~700 emails/giây)
NFR-2: Latency: transactional email < 30 giây từ trigger đến delivery
NFR-3: Availability: 99.95% uptime
NFR-4: Durability: không mất email đã queued
NFR-5: Scalability: horizontal scaling khi load tăng
NFR-6: Deliverability: inbox placement rate > 95%

3. 粗略估計

吞吐量計算

Target: 10 triệu emails trong 4 giờ
= 10,000,000 / (4 × 3,600)
= 10,000,000 / 14,400
≈ 694 emails/giây

Peak (2x): ~1,400 emails/giây
With headroom (3x): ~2,100 emails/giây

儲存估算

Email metadata per record: ~1 KB
  - recipient, subject, status, timestamps, tracking IDs

10 triệu emails × 1 KB = 10 GB metadata/campaign
Giữ 90 ngày history: 10 GB × 30 campaigns = 300 GB

Template storage: ~100 KB/template × 1000 templates = 100 MB
Total: ~300 GB database storage

頻寬估計

Average email size (rendered HTML): ~50 KB
10 triệu × 50 KB = 500 GB outbound/campaign
Throughput: 500 GB / 4 hours = 125 GB/h ≈ 280 Mbps

4. 發送大規模電子郵件時的挑戰

技術挑戰

ESP 的速率限制：Amazon SES 限制 200 封電子郵件/秒（預設），SendGrid 10,000 封/秒
IP 信譽：發送太快 → 標記為垃圾郵件
退回處理：硬退回需要立即從清單中刪除
連線管理：SMTP 連線池以提高效能
記憶體壓力：將數百萬筆記錄載入記憶體中

業務挑戰

送達率：電子郵件必須到達收件箱，而不是垃圾郵件資料夾
合規性：CAN-SPAM、GDPR、CCPA
成本：發送數百萬封電子郵件時優化成本
計時：在正確的時區、最佳時間發送
個人化：每個收件者的內容不同

5. 架構比較：Naive 與 Production

❌天真的方法

for each recipient in 10_million_list:
    render_template(recipient)
    send_email_via_smtp(recipient)
    save_to_database(status)

問題：

順序 → 丟失 1000 萬 × 0.5 秒 = ~58 天 😱
單點故障
失敗時不要重試
載入整個列表時記憶體溢出

✅ 製作方法（預覽）

API Request → Notification Service → Message Queue
    → Worker Pool (N workers) → Email Providers (multi-provider)
    → Webhook callbacks → Status tracking → Analytics

我們將在下一篇文章中深入探討這個架構。

6. 通知系統景觀

著名的通知系統

系統	規模	技術堆疊
Gmail/Google	每天 3000 億封電子郵件	客製化基礎設施
亞馬遜SES	10+ 十億/天	AWS 原生
SendGrid (Twilio)	100+十億/月	卡夫卡、Go、Redis
Mailchimp (Intuit)	6億/天	定制，山魈

開源替代品

郵政 - 郵件投遞平台（Ruby）
Mailtrain - 自託管新聞通訊 (Node.js)
Listmonk - 電子報和郵件清單（Go）
Novu - 通知基礎架構 (TypeScript)

總結

在本文中，您了解了：

為什麼發送數百萬封電子郵件的問題並不簡單？
功能性和非功能性要求
粗略估計
需要解決的挑戰
預覽生產架構

**下一篇：**我們將為整個系統設計High-Level Design架構。

第 1 課：通知系統概述 — 發送數百萬封電子郵件的問題

簡介