結論先講
每多一個服務就多一份維護成本。 Redis 確實快（5,346 RPS），ES 搜尋確實強（2.6 倍），Kafka 事件流確實穩。但你在 Day 1 就把它們全裝上去，你得到的不是高效能系統，是一個你維護不動的怪獸。正確做法是漸進式添加——只在痛點出現時才加對應服務，而且每次只加一個。
各服務的實測數據
Redis — 讀取加速器
| 指標 | 數據 | 篇章 |
|---|---|---|
| KV 讀取 | 5,346 req/s | [[micro-service/20-storage-redis-es|#20]] |
| Cache 加速效果（讀多場景） | +650% | [[micro-service/20-storage-redis-es|#20]] |
| 記憶體佔用（典型） | 50-200MB | [[micro-service/20-storage-redis-es|#20]] |
Redis 是 ROI 最高的加速方案——加幾行 code 就能把讀取效能提升 6.5 倍。但它是記憶體資料庫，資料量大時成本會爆炸。只放熱資料，設好 TTL。
Elasticsearch — 搜尋專家
| 指標 | 數據 | 篇章 |
|---|---|---|
| 搜尋速度 vs PG LIKE | 2.6 倍 | [[micro-service/56-search-mysql-pg-elk|#56]] |
| 中文分詞 + 模糊搜尋 | 原生支援 | [[micro-service/56-search-mysql-pg-elk|#56]] |
| 記憶體需求 | 最少 512MB | [[micro-service/56-search-mysql-pg-elk|#56]] |
ES 在搜尋場景無可取代，但它的維護成本高——索引同步、Mapping 管理、叢集健康監控都需要人力。在此之前，PG 的 pg_trgm + GIN index 可以撐到中等搜尋量。
PG JSONB vs MongoDB
PG JSONB 讀取只比 MongoDB 慢 4%，但寫入 MongoDB 快 8.6 倍（[[micro-service/20-storage-redis-es|#20]]）。如果你已經有 PG，JSONB 就能處理大部分半結構化需求，不需要多維護一個 MongoDB。
Kafka — 事件流處理
Kafka 適合事件驅動、服務解耦、流處理（[[micro-service/35-event-driven-basics|#57]]），但維護複雜度高。小規模場景 BullMQ 或 RabbitMQ 就夠了。除非每天處理百萬級事件，否則不需要 Kafka。
漸進式添加路線圖
階段 1：PG 打天下
[PG] ← 你的所有資料
適用：0-100 個用戶、MVP、新專案啟動
PG 能做到的事比你想像的多：
- 關聯式資料 → 正常 table
- 半結構化資料 → JSONB 欄位
- 全文搜尋 →
pg_trgm+ GIN index - 快取 → Materialized View
- Queue →
LISTEN/NOTIFY或pg_boss
在這個階段，你的瓶頸不是資料庫，是產品方向。不要花時間在架構上。
階段 2：PG + Redis
[PG] ← 寫入 + 複雜查詢
[Redis] ← 熱資料快取、Session、Rate Limiting
什麼時候加 Redis：
- 同一個 API 被重複呼叫，讀寫比超過 10:1
- 首頁或排行榜等高頻讀取頁面開始變慢
- 需要 Rate Limiting 或分散式鎖
- 用戶數超過 200 或 P95 回應時間超過 500ms
加 Redis 的成本很低（Docker 一行指令），效果很大（+650%）。這是最值得做的第一步擴展。
階段 3：PG + Redis + ES
[PG] ← 核心資料
[Redis] ← 快取
[ES] ← 搜尋
什麼時候加 ES：
- 搜尋量占總請求 20% 以上
- 需要中文分詞、模糊搜尋、自動補全
- PG
pg_trgm已經調到極限還是太慢 - 搜尋功能的 P95 回應時間超過 1 秒
加 ES 的成本明顯高於 Redis——你需要處理資料同步（PG → ES）、索引管理、至少 512MB RAM。確定你真的需要再加。
階段 4：PG + Redis + ES + Kafka
[PG] ← 核心資料
[Redis] ← 快取
[ES] ← 搜尋
[Kafka] ← 事件流、服務解耦、異步處理
什麼時候加 Kafka：
- 多個服務之間需要可靠的事件傳遞
- 每天事件量超過 100 萬筆
- 需要事件重放（event replay）能力
- BullMQ / RabbitMQ 已經撐不住
大部分應用永遠不會走到這一步。如果你只有 3-5 個微服務，RabbitMQ 甚至 BullMQ 就夠了。
常見錯誤
| 錯誤 | 為什麼是錯的 | 正確做法 |
|---|---|---|
| Day 1 裝 Redis + ES + Kafka | 維護成本 > 效能收益 | 從 PG only 開始 |
| 所有資料都放 Redis | 記憶體成本爆炸 | 只放熱資料、設 TTL |
| 用 MongoDB 取代 PG | 讀取只快 4%，失去關聯查詢 | PG JSONB 就夠 |
| 小流量就上 ES | ES 最少吃 512MB | 先用 PG pg_trgm |
| 用 Kafka 當 Message Queue | 殺雞用牛刀 | 小規模用 BullMQ / RabbitMQ |
判斷清單
在你決定加任何服務之前，問自己這三個問題：
- PG 原生方案試過了嗎？ JSONB、pg_trgm、Materialized View、LISTEN/NOTIFY
- 瓶頸確認了嗎？ 跑過壓測、看過 slow query log、確認真的是這個點
- 團隊能維護嗎？ 每個服務都需要監控、備份、升級、故障處理
三個都是 Yes 才加。
詳細數據見 [[micro-service/20-storage-redis-es|#20]]、[[micro-service/56-search-mysql-pg-elk|#56]]、[[micro-service/35-event-driven-basics|#57]]
下一篇
Infra 結論：架構模式與部署策略 — 儲存層搞定了，最後看架構和部署。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：DB 結論：資料庫選型與優化優先順序 → 下一篇：Infra 結論：架構模式與部署策略最終推薦