這個案例的核心責任是把「營運後轉換」變成可判讀決策，而不是技術潮流追逐。服務在成長期常會遇到早期選型與現況負載不再匹配，此時轉換的重點是風險收斂與效率改善，而不是語言偏好。

大量真實案例與轉換原因

案例分組判讀

語言與型別系統轉換

語言轉換常見於「延遲抖動不可接受」或「重構風險不可接受」兩類壓力。前者多是 runtime/記憶體模型問題，後者多是大型程式碼庫可維護性問題。

• 代表案例：Slack PHP -> Hack、Discord Go -> Rust、Dropbox Python 2 -> Python 3、Cloudflare C/NGINX -> Rust
• 主要動機：降低 tail latency、提升記憶體安全、對抗 runtime EOL、引入更強型別訊號

資料層與儲存架構轉換

資料層轉換通常源自單體資料庫在容量、隔離與可恢復性上出現結構性瓶頸，追新技術本身很少是真正驅動力。

• 代表案例：GitLab Main/CI split、Notion Postgres sharding、Shopify Vitess、Meta MyRocks
• 主要動機：解耦不同負載、降低熱點、取得水平擴充、降低儲存成本

平台與部署工具轉換

平台轉換通常發生在部署頻率提升後，原本的人工作業或弱自動化無法承擔發布風險。

• 代表案例：Figma 遷移 Kubernetes、Dropbox RPC 標準化到 gRPC
• 主要動機：統一部署控制面、縮短發布/回滾時間、提升跨語言協作效率

架構邊界重整

架構重整通常是「故障會跨邊界放大」或「團隊邊界與系統邊界失配」時的修正動作。

• 代表案例：Slack cellular architecture、Uber domain-oriented microservice governance
• 主要動機：縮小 blast radius、讓服務責任與組織責任對齊、降低跨團隊耦合

三倍擴充案例池（42）

這份案例池的核心責任是提供「可直接回寫實作」的案例母體，而不是只做公司清單。下面分成兩層：外部官方遷移案例（偏選型與轉換動機）與站內已整理案例（偏實作、驗證、事故教訓）。

A. 外部官方遷移案例（20）

B. 站內可回寫實作案例池（22）

這兩層合計 42 個案例。使用方式是先在 A 層找轉換動機，再到 B 層找可操作證據與失敗模式，最後回寫到 01/04/06/08 的正文。

跨分類覆蓋與缺口

這一段的核心責任是避免案例池被資料庫議題主導。選型與轉換在實務上會同時涉及快取、訊息傳遞、觀測、部署、安全與事故治理，因此案例覆蓋要跨分類配置。

覆蓋門檻與缺口追蹤

這份追蹤表的核心責任是把「案例夠不夠」變成可量化判斷，而不是主觀感覺。

下一輪優先順序

門檻已達標，下一輪優先順序改為：

1. 每分類補「失敗反例」與「轉換失敗回退案例」
2. 每分類補「同議題不同規模企業」對照
3. 把案例回寫到章節正文中的判讀訊號與 tripwire 欄位

回退失敗專題索引

這個索引的核心責任是讓讀者在「已經出錯」時，能快速找到對應回退失敗模式，而不是從頭重讀選型章節。

回退判讀寫法

回退判讀的核心責任是把失敗條件寫回該分類自己的業務語境。快取看的是回源壓力與資料新鮮度；queue 看的是語義、lag 與重播；observability 看的是訊號語意漂移；deployment 看的是切流、draining 與連線生命週期；security 看的是身份、憑證作用域與控制面擴散。

這些判讀不能抽成同一份模板。每次寫案例時，先回答該分類自己的問題：哪個業務路徑受影響、哪個訊號最早失真、哪個回退動作會降低傷害、哪份證據能證明回退有效。

下一輪補查清單（非 DB 優先）

下一輪補查會優先補目前中低密度分類，目標是讓每一類至少有 8 到 12 個可回寫案例。

1. Cache：快取策略遷移與失效治理（multi-layer、eviction、warmup）
2. Queue：broker/語義轉換與 replay 風險控制
3. Observability：監控平台遷移與資料品質治理
4. Deployment：部署平台轉換與灰度/回滾策略
5. Security：控制面信任邊界與憑證機制轉換

第二批外部案例補充（非 DB 類）

這一批的核心責任是把中低密度分類補到可用水位，讓 02/03/04/05/07 都有可引用的真實轉換案例，而不是只有資料庫案例可用。

第二批補查來源

• Meta：Cache consistency / mcrouter / CacheLib / Kangaroo / FOQS / MyRocks migration
• LinkedIn Engineering：Kafka at scale / TopicGC
• AWS：CloudHealth Kafka -> MSK、X-Ray -> OTel migration、ADOT/EKS 實務、EKS 遷移案例
• Google Cloud：OTLP in Cloud Trace、Orbitera -> GKE
• Shopify Engineering：cache serialization migration、write-through cache
• Cloudflare Post-mortem：2023/2026 control-plane 與路由事件

判讀訊號

轉換決策資料要求

轉換前要先回答的三個問題

1. 現有問題是「局部優化可解」還是「結構性不匹配」？
2. 轉換後的收益是性能、可靠性、開發效率哪一項，如何量化？
3. 遷移期間如何維持雙軌可運行與回退能力？

如果三個問題答不清楚，通常代表先做局部治理比全面轉換更穩定。

常見誤區

把「技術新舊」當成轉換理由，容易忽略遷移期成本。可靠做法是先界定症狀與邊界，再決定要換語言、換工具，或只換架構切分方式。

下一步路由

若問題在執行時特性（延遲抖動、記憶體模型），先回 0.2 與 0.5。若是資料庫轉換已進入執行階段，直接進 1.6 資料庫轉換實作；需要把 production migration 寫成 evidence、gate 與 decision log，接 1.7 Schema Migration Rollout 證據；需要放行與回滾治理時，接 6.11 Migration Safety；若要看事故層教訓，接 GitHub 2018 Oct21 MySQL Topology Incident。

引用源

• Hacklang at Slack: A Better PHP：Slack 說明 PHP 到 Hack 的遷移動機與型別收益。
• How Big Technical Changes Happen at Slack：Slack 逐步遷移與組織推進方式。
• Why Discord is switching from Go to Rust：Discord 說明 Go→Rust 的延遲與 GC 觀察。
• Slack’s Migration to a Cellular Architecture：Slack 從單體拓撲轉到 cell 架構的原因。
• The Long-Awaited Python 3 Upgrade at Dropbox：Dropbox 的 Python 2 -> 3 遷移動機與推進方式。
• Rewriting the heart of our sync engine：Dropbox 在核心效能路徑重寫的轉換決策脈絡。
• Courier: Driving the first years of gRPC：Dropbox 內部 RPC 到 gRPC 的演進背景。
• Splitting database into Main and CI：GitLab 的資料庫職責拆分案例。
• Sharding Postgres at Notion：Notion 分片遷移與容量壓力背景。
• Horizontally scaling the Rails backend of Shop App with Vitess：Shopify 導入 Vitess 的原因與方式。
• How Shopify Is Adopting Sorbet：Shopify 在大型 Ruby 程式碼庫導入型別系統。
• Migrating Figma to Kubernetes：Figma 的平台遷移原因與收益。
• A Rust regex engine in NGINX：Cloudflare 在高效能路徑導入 Rust 的案例。
• Domain-Oriented Microservice Architecture：Uber 在規模化後重整服務邊界。
• MyRocks: A space- and write-optimized MySQL database：Meta 導入 MyRocks 的成本與效能動機。