公開案例量是 vendor 社群活躍度 signal
公開案例量是 vendor 社群活躍度 signal
結論
公開 customer engineering case 的累積量、是 vendor 社群活躍度跟長期可維護性的信號。case 多寡跟 vendor 工程能力沒有線性關係、跟以下因素相關：
- 社群活躍度（用戶數 + 用戶寫 blog 文化）
- Vendor 自身的 customer success / DevRel 投入
- Feature 成熟度（新 feature 公開 case 通常稀薄）
- 議題公開度（內部運維議題公司不常寫、incident / migration 容易寫）
選型時、公開 case 量值得作為信號之一、但要跟「該 vendor 是否仍積極開發」「文檔品質」「社群 issue 回應速度」等其他信號合併判讀。
為什麼
backend/03-message-queue 模組 6 vendor 案例採集發現 case 累積量差異極大：
| Vendor | 採集前案例 | 公開可採集案例（5-10 目標） | 累積差異 |
|---|---|---|---|
| Kafka | 已有 8 個 | 12 個新案例（容易找） | 案例豐富 |
| RabbitMQ | 0（待補） | 11 個新案例 | 中等豐富 |
| AWS SQS | 0（待補） | 12 個新案例 | 豐富（managed service 客戶多） |
| Google Pub/Sub | 0（待補） | 10 個新案例（Mercari/Spotify 集中） | 中等 |
| NATS | 0（待補） | 8 個新案例（部分依 Synadia partner blog） | 中等偏少 |
| Redis Streams | 0（待補） | 6 個新案例（不少公司用 Redis 但少寫 Streams） | 偏少 |
差異不只是「採集力度」、是公開資料密度本身差異。
反模式
選型時誤用案例量的方式：
| 反模式 | 問題 |
|---|---|
| 「Kafka case 比 NATS 多、所以選 Kafka」 | 把 case 量當技術品質訊號、忽略需求形狀對齊（NATS 對 microservices messaging 可能更合適） |
| 「Redis Streams case 少、所以不該用」 | 把案例稀薄當不成熟訊號、但 Redis Streams 在 Redis 生態內已是常見 pattern、只是公司不常單獨寫 blog |
| 「Pub/Sub case 集中在 Spotify + Mercari、所以代表性不足」 | 大公司多篇深度 case 比中等公司零散 case 教學價值更高、累積量不等於覆蓋廣度 |
修法
選型時把案例量當合併信號之一、跟以下信號交叉判讀：
- 議題對齊度：該 vendor 的 case 是否覆蓋你的需求形狀（吞吐 / 延遲 / 持久化 / 多租戶 / 跨區）？
- Vendor 活躍度：GitHub release 節奏、issue 回應速度、CVE 修復時間
- 生態整合：是否有你需要的 client library / framework / observability 工具
- 社群健康：Stack Overflow 問題回答率、Discord / Slack 活躍度
- 長期承諾：vendor 公司 / 基金會背景、license 模式、商業化路徑
單看案例量會誤導、但完全忽略也會錯失重要信號：某些 vendor 案例量低反映社群活躍度低、選型後遇到問題找不到參考、自己要從零摸索。
關係
- 跟採集流程的關係：採集到「該 vendor 公開 case 偏少」是真實信號、不是採集失敗、不該強求 10 個案例
- 跟 case-driven 寫作的關係：公開 case 稀薄的章節改走 standard-driven 或通用工程知識補強、明示覆蓋缺口
- 跟 vendor 選型的關係：案例量是合併信號之一、不是主要判讀依據
case
backend/03-message-queue 模組採集後盤點：
- Kafka 17+ 案例、議題覆蓋廣度高、但 KRaft / 部分新 feature 仍稀薄
- NATS 8 案例、議題集中在 IoT / edge / multi-cloud、其他場景偏少
- Redis Streams 6 案例、Stream + Functions / Cluster on Streams 缺、是 feature 成熟度信號
- Pub/Sub Mercari 4 篇深度 case 是 anchor cluster、品質高過案例量
選型時把這些差異當輔助信號、不當主判讀。
判讀徵兆
何時案例量該升為主要選型信號：
- 該領域有很多 vendor 都做類似功能（如 message broker 有 7+ 個 vendor）、案例量可以區分活躍度
- 該 vendor 是新興 / 商業化不確定（vendor lock-in 風險）、需要評估社群獨立性
- 該 vendor 過去有 license 改變或商業化轉向（Redis / Elasticsearch / MongoDB）、社群 fork 的活躍度該追蹤
何時案例量不該當主要信號：
- 需求形狀已有明確 vendor 對齊（如 GCP 生態下 Pub/Sub 是預設）
- Vendor 公司本身極穩定（AWS / Google managed service）
- 主要 case 集中在反例 / 退場案例（這時案例多反而是負面信號）