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

概念定位

這一頁的責任是回答三件事:這家公司遇到什麼壓力、做了什麼選型決策、代價與回寫是什麼。提供企業層面的選型壓力對照,跟 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.20.5
DevTool(成長期,職能拆分)GitLab: Splitting Main and CI DB功能分解如何換取容量與可靠性0.20.6
DevTool(成熟期,升級風險控制)GitLab: Major PostgreSQL Upgrade高流量環境下升級策略與回退設計0.706
Commerce(高速成長,資料庫升級)Shopify: Upgrading MySQL大規模 MySQL 維運成本與可靠性治理0.20.6
Commerce(超大規模,水平擴充)Shopify: Scaling with Vitess什麼時候引入 Vitess 以取得水平擴充能力0.10.5
Social / Chat(高吞吐事件流)Slack: Scaling Job Queue高吞吐背景工作為何改採 Kafka + Redis0.303
Social(超大規模,多租戶優先序)Meta: FOQS Distributed Priority Queue多租戶 priority queue 如何做持久化與隔離0.30.6
Ride-hailing(全球規模,監控平台)Uber: M3 Metrics Platform單點監控系統何時要走平台化與多租戶存儲0.404
CDN / Security(邊緣規模,可觀測)Cloudflare: Building Cloudflare on Cloudflarelogs/metrics/traces 如何一起成為操作能力0.44.20
Commerce(成熟期,韌性驗證)Shopify: Effective Game Day Tests如何把演練從活動變成驗證制度0.706
Commerce(大促前容量治理)Shopify: Resiliency Planning for High-Traffic Events高峰活動前容量與風險如何建模0.56.9
Cloud Platform(多租戶隔離)AWS Builders’ Library: Shuffle-sharding多租戶故障隔離如何影響資料與佇列設計0.60.7
Platform(組織擴張,邊界重整)Uber: Domain-Oriented Microservice Architecture微服務規模變大後如何重新治理邊界與依賴0.00.1
Social(儲存成本壓力)Meta: MyRocks何時用新 storage engine 換取成本與寫入效率0.20.6
Social(平台化分片)Meta: Shard Manager分片能力何時應該平台化而不是各隊自建0.10.7

類型覆蓋檢查

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

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

第一批缺口回填清單

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

缺口類型優先蒐集的選型議題回寫章節起點
FinTech合規壓力下的資料分區、審計留存、變更放行與風險隔離0.60.8
Gaming高峰事件流、低延遲路徑、規則推送風險與跨區回復0.30.5
Healthcare資料主權、存取邊界、可追溯性與災難回復流程0.20.8

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

第一批案例清單(FinTech / Gaming / Healthcare)

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

類型企業案例主要選型問題優先回讀章節
FinTechStripe: Scaling Payments APIs金流 API 的一致性、冪等與放行門檻0.20.6
FinTechAdyen Engineering合規要求下的資料保留、稽核追溯與跨區部署0.80.7
GamingRiot Games Tech Blog高峰活動期間的低延遲路徑與跨區容量治理0.50.3
GamingEpic Games Unreal Engine / Fortnite Scale Articles大型即時服務的事件流、匹配與故障隔離0.30.6
HealthcareGoogle Cloud Healthcare Architecture Guides資料主權、存取邊界與審計證據鏈0.80.2
HealthcareAWS Healthcare and Life Sciences Architecture多區備援下的資料保護與恢復順序0.70.8

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

對應正文入口

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

類型正文入口
FinTech0.C1 FinTech:合規壓力下的後端選型
Gaming0.C2 Gaming:高峰流量與隔離邊界選型
Healthcare0.C3 Healthcare:資料主權與回復順序選型

營運一段時間後的語言、工具或架構轉換案例,見 0.C4 營運後技術轉換

讀法提醒

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

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