企業選型案例圖譜的核心責任是提供「跨規模、跨產業、跨階段」的選型樣本，讓讀者知道同一種技術問題在不同公司會如何被定義、取捨與落地。

概念定位

這一頁的責任是回答三件事：這家公司遇到什麼壓力、做了什麼選型決策、代價與回寫是什麼。提供企業層面的選型壓力對照，跟 0.19 雲端服務對照地圖 是 sibling：本頁是「實際企業怎麼決策」、0.19 是「能力 × vendor 名稱對照」。兩者並讀能避免「光看對照表選 vendor」或「光看案例抄架構」的兩種誤用。

使用方式是先從你的需求壓力切入，再對照對應案例，而不是先選喜歡的公司再倒推技術。這樣可以避免「抄架構」而忽略上下文差異。

使用方式

  1. 先回到 0.0 後端需求分類地圖 定位你的問題類型。
  2. 用本頁找 2 到 3 個不同規模企業的對照案例。
  3. 把案例中的決策壓力回寫到 0.6 成本、風險與選型取捨。
  4. 再進入對應模組（01-08）看實作與控制面細節。

案例地圖

案例按照「企業型態 × 規模階段」分組，目的是讓你先找到最接近自己情境的壓力來源，再看選型動作。

企業型態與規模階段企業案例主要選型問題優先回讀章節
SaaS（成長期，單體資料庫瓶頸）Notion: Sharding Postgres單體 Postgres 何時拆分成分片架構0.2 狀態與資料儲存選型、0.5 流量與資料量評估
DevTool（成長期，職能拆分）GitLab: Splitting Main and CI DB功能分解如何換取容量與可靠性0.2 狀態與資料儲存選型、0.6 成本、風險與選型取捨
DevTool（成熟期，升級風險控制）GitLab: Major PostgreSQL Upgrade高流量環境下升級策略與回退設計0.7 錯誤定位、觀測訊號與備援切換設計、06
Commerce（高速成長，資料庫升級）Shopify: Upgrading MySQL大規模 MySQL 維運成本與可靠性治理0.2 狀態與資料儲存選型、0.6 成本、風險與選型取捨
Commerce（超大規模，水平擴充）Shopify: Scaling with Vitess什麼時候引入 Vitess 以取得水平擴充能力0.1 後端服務能力地圖、0.5 流量與資料量評估
Social / Chat（高吞吐事件流）Slack: Scaling Job Queue高吞吐背景工作為何改採 Kafka + Redis0.3 非同步與事件傳遞選型、03
Social（超大規模，多租戶優先序）Meta: FOQS Distributed Priority Queue多租戶 priority queue 如何做持久化與隔離0.3 非同步與事件傳遞選型、0.6 成本、風險與選型取捨
Ride-hailing（全球規模，監控平台）Uber: M3 Metrics Platform單點監控系統何時要走平台化與多租戶存儲0.4 操作平台選型、04
CDN / Security（邊緣規模，可觀測）Cloudflare: Building Cloudflare on Cloudflarelogs/metrics/traces 如何一起成為操作能力0.4 操作平台選型、4.20 Observability Evidence Package
Commerce（成熟期，韌性驗證）Shopify: Effective Game Day Tests如何把演練從活動變成驗證制度0.7 錯誤定位、觀測訊號與備援切換設計、06
Commerce（大促前容量治理）Shopify: Resiliency Planning for High-Traffic Events高峰活動前容量與風險如何建模0.5 流量與資料量評估、6.9 容量與成本邊界
Cloud Platform（多租戶隔離）AWS Builders’ Library: Shuffle-sharding多租戶故障隔離如何影響資料與佇列設計0.6 成本、風險與選型取捨、0.7 錯誤定位、觀測訊號與備援切換設計
Platform（組織擴張，邊界重整）Uber: Domain-Oriented Microservice Architecture微服務規模變大後如何重新治理邊界與依賴0.0 後端需求分類地圖、0.1 後端服務能力地圖
Social（儲存成本壓力）Meta: MyRocks何時用新 storage engine 換取成本與寫入效率0.2 狀態與資料儲存選型、0.6 成本、風險與選型取捨
Social（平台化分片）Meta: Shard Manager分片能力何時應該平台化而不是各隊自建0.1 後端服務能力地圖、0.7 錯誤定位、觀測訊號與備援切換設計

類型覆蓋檢查

案例蒐集的完成條件是覆蓋度，篇數本身沒有意義。每次補案例都用這四個維度檢查缺口。

維度已覆蓋示例常見缺口
企業型態SaaS、DevTool、Commerce、Social、Ride-hailing、Cloud Platform、CDN/SecurityFinTech、Gaming、Healthcare、製造業平台
規模階段成長期、成熟期、超大規模早期產品（小團隊）與跨國多區治理
選型問題類型資料分片、佇列架構、可觀測平台、容量韌性、多租戶隔離、組織邊界成本治理、合規（PCI/SOX/GDPR）與資料主權
決策生命週期遷移、升級、平台化、演練退場策略（decommission）與 vendor 轉移

第一批缺口回填清單

第一批回填先補三個目前缺口最大的產業類型，目標是讓案例圖譜從「網路平台公司視角」擴展到「高合規與高事件密度」場景。

缺口類型優先蒐集的選型議題回寫章節起點
FinTech合規壓力下的資料分區、審計留存、變更放行與風險隔離0.6 成本、風險與選型取捨、0.8 資安與資料保護需求
Gaming高峰事件流、低延遲路徑、規則推送風險與跨區回復0.3 非同步與事件傳遞選型、0.5 流量與資料量評估
Healthcare資料主權、存取邊界、可追溯性與災難回復流程0.2 狀態與資料儲存選型、0.8 資安與資料保護需求

這份清單的用途是定義下一輪蒐集方向。每補一個案例，至少要同步回寫一個 04 觀測章節、一個 06 驗證章節與一個 08 事故章節，避免案例只停留在選型敘事。

第一批案例清單（FinTech / Gaming / Healthcare）

第一批案例的責任是先補齊產業覆蓋，並建立可直接回寫到 04/06/08 的共同語言。

類型企業案例主要選型問題優先回讀章節
FinTechStripe: Scaling Payments APIs金流 API 的一致性、冪等與放行門檻0.2 狀態與資料儲存選型、0.6 成本、風險與選型取捨
FinTechAdyen Engineering合規要求下的資料保留、稽核追溯與跨區部署0.8 資安與資料保護需求、0.7 錯誤定位、觀測訊號與備援切換設計
GamingRiot Games Tech Blog高峰活動期間的低延遲路徑與跨區容量治理0.5 流量與資料量評估、0.3 非同步與事件傳遞選型
GamingEpic Games Unreal Engine / Fortnite Scale Articles大型即時服務的事件流、匹配與故障隔離0.3 非同步與事件傳遞選型、0.6 成本、風險與選型取捨
HealthcareGoogle Cloud Healthcare Architecture Guides資料主權、存取邊界與審計證據鏈0.8 資安與資料保護需求、0.2 狀態與資料儲存選型
HealthcareAWS Healthcare and Life Sciences Architecture多區備援下的資料保護與恢復順序0.7 錯誤定位、觀測訊號與備援切換設計、0.8 資安與資料保護需求

這批案例以「產業壓力類型」為主，不以單一公司唯一做法當標準答案。後續第二批再補製造業平台與跨國多區治理案例。

對應正文入口

第一批缺口已補對應正文，圖譜可直接連到可回寫文章：

類型正文入口
FinTechFinTech：合規壓力下的後端選型
GamingGaming：高峰流量與隔離邊界選型
HealthcareHealthcare：資料主權與回復順序選型

營運一段時間後的語言、工具或架構轉換案例，見 營運後技術轉換。

讀法提醒

同一家公司不代表同一答案。公司不同時期的選型結論可能相反，因為負載、組織、預算與產品階段已經改變。把案例當成「決策壓力樣本」，比當成「標準答案」更可靠。

當兩個案例做出不同選擇，先檢查四件事：流量形狀、資料生命週期、失敗代價、維運能力。這四件事通常比語言與框架更能解釋選型差異。