Tarragon

"Backend"

• 2026-06-23 Chaos Mesh：Workflow、Scope Control 與 Steady State Probe 用 Chaos Workflow 編排多步驟實驗、用 selector 與 mode 控制 blast radius、用 StatusCheck 做 steady state probe。
• 2026-06-23 k6：Threshold CI Gate 與 Scenario 設計 用 threshold 把 load test 結果變成 CI pass/fail，用 scenario 讓 workload model 貼近 production traffic shape。
• 2026-06-23 Sloth：SLO YAML 與 Multi-burn-rate Alert 生成 用宣告式 YAML 定義 SLO，自動生成 Prometheus multi-window multi-burn-rate recording 與 alerting rules。
• 2026-05-27 10.1 服務拆分與邊界判讀 整理 monolith vs microservice 取捨、服務邊界判讀訊號、拆分時機與回退路徑
• 2026-05-27 DB3 Vendor Selection：document / KV / multi-model 三方選型 + workload shape 前置判讀 MongoDB / DynamoDB / Cosmos DB 三家 NoSQL 選型 entry point：workload shape × access pattern × consistency 三軸前置判讀、migration path 三型、federated DB 視角、三 vendor 對比 10 軸
• 2026-05-21 後端 migration、rollout 與 rollback 流程 說明後端 CI/CD 如何把程式、資料 migration、流量切換與 rollback 拆成可驗證的發布流程
• 2026-05-13 1.1 高併發下的 SQL 讀寫邊界 說明高併發服務如何共用資料庫 client、控制 transaction、管理 connection pool、避免資料庫成為瓶頸
• 2026-05-12 9.1 壓測理論與系統行為 Little's Law、queueing theory、USL、saturation curve 在容量規劃中的角色
• 2026-05-12 9.C1 AWS Prime Day 2025：可預期極端峰值的 dogfood Amazon 自家服務在 Prime Day 2025 的峰值數字 — 一年一次可預期峰值的容量設計參考
• 2026-05-07 2.C1 Meta：Cache Consistency 升級 快取 invalidation 一致性如何從常見錯誤演進到高可信治理。
• 2026-05-07 3.C1 Meta：FOQS 從區域到全域佇列遷移 佇列架構如何在不中斷下升級成 disaster-ready 模式。
• 2026-05-07 5.C1 Tradeshift：self-managed Kubernetes 遷移到 EKS 零停機平台遷移的分段策略案例。
• 2026-05-07 7.C1 Cloudflare：2026 Route Leak 事件 BGP 路由政策自動化失誤如何回寫控制面治理。
• 2026-05-07 Atlassian 2022 April Multi-tenant Deletion Outage 2022-04 Atlassian 因維運腳本誤刪多租戶站點造成長時間事故的解析：恢復分批、跨團隊指揮與對外通訊節奏。
• 2026-05-07 AWS S3 2017 US-EAST-1 Service Disruption 2017-02-28 AWS S3 us-east-1 事故解析：內部操作命令、index / placement 子系統重啟、區域依賴擴散與狀態頁依賴回寫。
• 2026-05-07 Cloudflare 2019 Regex CPU Outage 2019-07-02 Cloudflare WAF 規則更新導致全球 CPU 飆升的事故解析：觸發條件、擴散機制、止血決策與可回寫控制面。
• 2026-05-07 Fastly 2021 June Global Edge Config-triggered Outage 2021-06-08 Fastly 全球 edge 事故解析：有效客戶配置觸發潛藏 bug、分鐘級擴散與快速隔離恢復。
• 2026-05-07 FinTech：合規壓力下的後端選型 在審計、留存與交易正確性要求下，如何平衡成本、風險與交付速度。
• 2026-05-07 FinTech：審計證據鏈的可觀測性設計 把交易與存取事件轉成可回查證據，降低合規審核與事故判讀落差。
• 2026-05-07 GCP 2019 US Network Congestion Multi-service Incident 2019-06-02 Google Cloud 因美國區域網路壅塞造成多服務退化的事故解析：跨產品依賴、流量控制與區域隔離判讀。
• 2026-05-07 GitHub 2018 Oct21 MySQL Topology Incident 2018-10-21 GitHub 因 network partition 觸發跨區資料庫拓撲異常的事故解析：資料一致性優先、fail-forward 決策與長時間恢復。
• 2026-05-07 Roblox 2021 Oct Prolonged Core Infra Outage 2021-10 Roblox 長時間平台中斷的事故解析：核心基礎設施壓力失衡、根因定位延遲與長尾恢復。
• 2026-04-23 0.1 後端服務能力地圖 用需求類型判斷應先評估資料庫、快取、訊息佇列、觀測平台或部署平台
• 2026-04-23 3.1 broker 基礎與投遞模型 先理解 broker、queue、consumer 與 delivery semantics
• 2026-04-23 4.1 log schema 與搜尋規劃 整理 log 欄位、索引與搜尋策略
• 2026-04-23 5.1 container 與 runtime 整理 image、resource limit 與啟動行為
• 2026-04-23 6.1 CI pipeline CI pipeline 的分層策略、artifact 管理、flaky 治理與 release gate 輸入
• 2026-04-23 8.1 事故分級與啟動條件 建立統一分級標準與事故啟動門檻
• 2026-04-22 2.1 高併發下的 Redis 讀寫邊界 說明高併發服務如何共用 Redis client、控制 pipeline 與避免 cache stampede
• 2026-06-23 GitHub Actions：Environment Protection 與 OIDC Cloud Auth 用 environment protection rules 做 deploy approval gate、用 OIDC 取代 long-lived cloud credential。
• 2026-05-27 10.2 服務拆分執行 Runbook（Strangler Fig / 雙寫期 / 切流 / 回退） 10.1 決定該拆之後、實際怎麼動手拆 — Strangler Fig pattern、雙寫期管理、切流策略、回退條件設計
• 2026-05-13 1.2 Schema Design 與資料建模 整理 table、index、key、partition、denormalization 與命名規則
• 2026-05-12 9.2 Workload Modeling 把 production traffic shape 翻成可重播的壓測模型
• 2026-05-12 9.C2 GR8 Tech：AI 預測式自動擴容下的體育博彩高峰 AI 預測 + EKS 自動擴容怎麼在 25ms p95 下承載 54000 TPS 體育博彩峰值流量
• 2026-05-07 2.C2 Meta：mcrouter 與跨區快取路由 快取從單點最佳化演進到分散式路由層的案例。
• 2026-05-07 3.C2 VMware Tanzu CloudHealth：Kafka 轉 Amazon MSK 自管 Kafka 遷移到託管平台時的治理重點。
• 2026-05-07 5.C2 Condé Nast：EKS 平台整併與標準化 多地區異質 Kubernetes 平台整併為統一控制面的案例。
• 2026-05-07 7.C2 Cloudflare：2023 Control-plane Token 事件 控制面 token 事件如何回寫 secrets 與機器憑證治理。
• 2026-05-07 AWS 2021 US-EAST-1 Control Plane Degradation 2021-12-07 AWS us-east-1 控制面退化案例：內部網路壅塞、API 錯誤率升高、跨服務依賴連鎖與通訊節奏調整。
• 2026-05-07 Cloudflare 2023 Control Plane Token Incident 2023-01-24 Cloudflare service token 錯誤變更導致多產品連鎖影響的事故解析：信任邊界、擴散機制、止血策略與流程回寫。
• 2026-05-07 Gaming：高峰流量下的訊號新鮮度與 Cardinality 在高峰事件中控制訊號延遲與維度爆炸，維持告警與定位可信度。
• 2026-05-07 Gaming：高峰流量與隔離邊界選型 大型活動流量下，如何在低延遲與穩定性之間做可持續取捨。
• 2026-04-23 0.2 狀態與資料儲存選型 區分 source of truth、快取、搜尋索引、event log 與 object storage 的選型邊界
• 2026-04-23 2.2 cache aside 與失效策略 整理 read-through 思路、cache miss 與 invalidation
• 2026-04-23 3.2 durable queue 與重試策略 整理持久化佇列、DLQ 與重試流程
• 2026-04-23 4.2 metrics 與 SLI/SLO 整理 counter、gauge、histogram 與服務健康指標
• 2026-04-23 5.2 Kubernetes 部署策略 整理 deployment、probe 與 rolling update
• 2026-04-23 6.2 load test 把 production 流量結構轉成可重播壓力情境，定位 saturation 轉折與容量邊界
• 2026-04-23 8.2 事故指揮與角色分工 定義 incident commander 與跨角色協作責任
• 2026-06-22 4.3 tracing 與 context link 整理 trace id、span 與跨服務 context propagation
• 2026-06-11 10.3 託管形態遷出：資產線盤點與並行期執行 0.21 升級自建 tripwire 觸發後的執行劇本 — 把遷出拆成資料、身分、流量、整合各自的可攜性與斷點、設計舊平台與新系統的並行期與回切窗口、用部分遷出作為中繼形態
• 2026-05-13 1.3 Transaction 與一致性邊界 交易邊界、isolation level、retry 策略、distributed transaction（2PC、Saga）與跨 region 強一致取捨
• 2026-05-12 9.3 壓測工具選型 k6 / JMeter / Gatling / Locust / Vegeta / Production Replay 的工程選型
• 2026-05-12 9.C3 Coinbase International Exchange：超低延遲交易的逆向容量設計 為什麼 Coinbase 國際交易所選 Cluster Placement Group + z1d 而不是自動擴容 — 延遲敏感型負載的容量取捨
• 2026-05-08 AWS：Control Plane 事故的責任邊界與通訊節奏樣式（2023） 以 AWS 2023 年公開事件樣式為主，整理 control plane 退化時如何建立責任邊界、決策紀錄與對外更新節奏。
• 2026-05-07 2.C3 Shopify：快取序列化格式遷移 快取 payload 從 Marshal 轉 MessagePack 的遷移策略。
• 2026-05-07 3.C3 LinkedIn：TopicGC 與 Kafka 治理轉換 Kafka topic 從手動治理轉自動治理對叢集的影響。
• 2026-05-07 5.C3 Orbitera：遷移到 Managed Kubernetes 平台重置時如何讓產品不中斷地完成編排層轉換。
• 2026-05-07 7.C3 Azure AD：2021 Identity Control-plane 事件 身分控制面事件如何影響多服務信任鏈與回復優先序。
• 2026-05-07 Cloudflare 2026 BYOIP BGP Withdrawal 2026-02-20 Cloudflare BYOIP prefixes 被非預期撤告的事故解析：Addressing API bug、BGP withdrawal、狀態恢復與控制面回寫。
• 2026-05-07 Healthcare：存取可追溯性與保留邊界 在資料主權限制下，建立可追溯存取證據與分層保留策略。
• 2026-05-07 Healthcare：資料主權與回復順序選型 醫療場景下，如何把資料主權、存取邊界與災難回復放進同一套決策。
• 2026-04-23 0.3 非同步與事件傳遞選型 區分背景工作、durable queue、stream、pub/sub 與 outbox 的選型邊界
• 2026-04-23 2.3 TTL 與 eviction 整理過期策略、容量控制與熱點資料
• 2026-04-23 3.3 outbox pattern 與發佈一致性 把 transaction 與 event publish 分離
• 2026-04-23 5.3 load balancer 合約 整理 idle timeout、draining 與 health check
• 2026-04-23 6.3 fuzz campaign 用自動化輸入探索覆蓋未知邊界：target 設計、corpus 管理、crash reproduction 與 CI 整合
• 2026-04-23 8.3 止血、降級與回復策略 把短期止血與正式回復拆成可執行步驟
• 2026-06-22 4.4 dashboard 與 alert 設計 讓 dashboard 與 alert 對應 runbook 與容量趨勢
• 2026-05-13 1.4 Repository Adapter 實作 Port / Adapter 邊界、row mapping、error translation、ORM vs query builder 選型、contract test 設計
• 2026-05-12 9.4 Saturation Discovery 找出 throughput plateau 與 latency knee 的方法
• 2026-05-12 9.C4 DraftKings：Aurora 撐 100 萬 ops/min 的體育博彩金融帳本 DraftKings 用 Aurora MySQL 跑體育博彩金融帳本、Super Bowl 流量 +50% 不影響延遲
• 2026-05-07 2.C4 Meta：CacheLib / Kangaroo 分層快取 快取從 DRAM-only 轉向分層快取架構的實務案例。
• 2026-05-07 3.C4 LinkedIn：Kafka 分層叢集治理 Kafka 從單叢集走向 tiered clusters 的轉換案例。
• 2026-05-07 4.C4 AWS：X-Ray 到 OpenTelemetry 轉換 觀測儀表從 vendor-specific SDK 轉向 OpenTelemetry 的治理重點。
• 2026-05-07 5.C4 Mobileye：Workloads 遷移到 EKS 大規模工作負載遷移到 managed Kubernetes 的分段治理案例。
• 2026-05-07 7.C4 Microsoft：Storm-0558 簽章金鑰事件 簽章金鑰事件如何回寫 identity 信任邊界與觀測證據鏈。
• 2026-05-07 Cloudflare 2023 Workers KV Deployment Tool Misconfiguration 2023-10-30 Cloudflare 控制面事故：deployment tool 設定錯誤造成 Workers KV 連鎖影響，重點在變更範圍限制與決策回寫。
• 2026-05-07 營運後技術轉換：語言、工具與架構何時該換 服務營運一段時間後，如何判讀何時該轉語言、工具或架構，並用案例說明轉換動機。
• 2026-04-23 0.4 操作平台選型 區分 log、metric、trace、dashboard、alert、deployment 與 reliability 的選型邊界
• 2026-04-23 2.4 distributed lock 與租約 整理鎖語意、租約風險與適用場景
• 2026-04-23 3.4 consumer 設計與去重 整理 consumer、checkpoint 與 replay safety
• 2026-04-23 5.4 service discovery 整理 endpoint discovery 與 DNS
• 2026-04-23 6.4 chaos testing 把故障注入從工具操作升級成可驗證流程：先定義穩態，再按依賴類型設計注入、控制 blast radius 與收集證據
• 2026-04-23 8.4 事故通訊與狀態更新 建立內外部通報節奏與狀態更新格式
• 2026-06-22 4.5 可觀測性威脅建模（Threat Modeling） 從觀測盲區、告警失真與資料暴露風險，盤點 observability 的主要弱點
• 2026-05-13 1.5 攻擊者視角（紅隊）：資料層弱點判讀 從資料存取邊界、外洩路徑與修復代價、盤點 database 的主要弱點
• 2026-05-12 9.5 瓶頸定位流程 從 app 到 DB / cache / broker / 第三方 quota 的逐層瓶頸定位
• 2026-05-12 9.C5 Amazon Ads：DynamoDB 9000 萬 reads/sec 的廣告事件量測 Amazon Ads 在 DynamoDB 上跑 9000 萬 reads/sec + 500 萬 writes/sec、99.999% 可用性的廣告事件量測
• 2026-05-07 2.C5 Shopify：Write-through Cache 在高讀流量的實作 read-heavy 服務如何轉向 write-through 快取模型。
• 2026-05-07 3.C5 Slack：Job Queue 演進到 Kafka + Redis 背景工作通道在成長期如何從單一路徑演進成組合式架構。
• 2026-05-07 4.C5 Google Cloud：Cloud Trace 導入 OTLP 入口 觀測平台從專有入口擴展到 OTLP 標準通道的案例。
• 2026-05-07 5.C5 Miro：Managed EKS 遷移 從自維運平台轉向 managed EKS 的組織與技術協同案例。
• 2026-05-07 7.C5 Okta：2023 Support System 事件 支援系統憑證風險如何擴散到客戶租戶的案例。
• 2026-04-24 3.5 攻擊者視角（紅隊）：傳遞層弱點判讀 從重複投遞、重放濫用、毒訊息與容量壓力，盤點 message delivery 的主要弱點
• 2026-04-24 5.5 平台與入口威脅建模（Threat Modeling） 以概念層判讀部署平台弱點，聚焦入口、生命週期、設定與交付節奏
• 2026-04-24 6.5 失敗模式預判（Pre-mortem 與 FMEA） 用 pre-mortem 反向推導失敗路徑、用 FMEA 分類軸評估驗證缺口，把可靠性盲區變成可排序的改善輸入
• 2026-04-23 0.5 流量與資料量評估 用流量形狀、資料成長、hot key、保留期限與尖峰模式評估後端需求規模
• 2026-04-23 2.5 presence store 與即時狀態 整理線上狀態、跨節點查詢與過期清理
• 2026-04-23 8.5 復盤與改進追蹤 把 RCA 與 action items 轉成可驗證閉環
• 2026-06-22 4.6 SLI 量測與 SLO 訊號設計 把可靠性目標的訊號從 metric 端設計好、餵給 6.6 SLO 政策
• 2026-05-13 1.6 資料庫轉換實作：雙寫、回填、切流與回滾 同 DB 內 schema 演進與資料變更的可分段驗證流程、跟 1.12 cross-DB migration 分工
• 2026-05-12 9.6 容量規劃模型 peak forecast、headroom budget、growth curve、autoscaling sizing
• 2026-05-12 9.C6 Tinder：ElastiCache for Valkey 撐 4700 萬月活的配對引擎 Tinder 用 Amazon ElastiCache for Valkey 提供配對引擎所需的次毫秒延遲快取層
• 2026-05-11 3.6 Processing Semantics 與 Recovery Semantics 說明投遞成功、處理成功與恢復成功為何是三個不同判斷。
• 2026-05-11 5.6 Platform Lifecycle Contract 說明 runtime、startup、readiness、liveness、shutdown 與 drain 如何組成平台生命週期合約。
• 2026-05-07 2.C6 Netflix：EVCache 全域快取層 快取從本地層演進為跨區分散式能力的案例。
• 2026-05-07 3.C6 Uber：Kafka 事件平台演進 事件平台從團隊自管走向多租戶共享基礎設施。
• 2026-05-07 4.C6 AWS：ADOT on EKS 管線遷移 從分散式 agent 組合轉成 OpenTelemetry collector 管線治理。
• 2026-05-07 5.C6 Airbnb：Kubernetes 叢集擴縮演進 從手動擴縮走向自動化容量治理的部署平台案例。
• 2026-05-07 7.C6 Okta：Cross-tenant Impersonation 防禦回寫 跨租戶 impersonation 風險如何轉成身份治理與偵測策略。
• 2026-05-01 6.6 SLO 與 Error Budget 政策 把可靠性目標轉成可驗證量測與凍結條件
• 2026-04-24 2.6 快取威脅建模（Threat Modeling） 從快取污染、一致性偏移與流量放大風險，盤點 cache/redis 的主要弱點
• 2026-04-23 0.6 成本、風險與選型取捨 用人力成本、雲端成本、操作成本與失敗代價判斷後端能力投入順序
• 2026-04-23 8.6 演練與值班能力建設 用演練與值班訓練提升事故反應品質
• 2026-05-12 9.7 成本邊界與 efficiency cost per request、cost curve、降級成本、over-provisioning trade-off
• 2026-05-12 9.C7 Lyft：100+ 微服務在 8 倍峰值下的 Auto Scaling Lyft 用 AWS Auto Scaling 跨 100+ 個微服務承載 8 倍峰值流量、跨 200+ 城市
• 2026-05-11 1.7 Schema Migration Rollout 證據（Schema Migration Rollout Evidence）實作示範 以訂單付款狀態欄位演進示範 schema migration 如何產出 evidence、release gate 與 incident decision log。
• 2026-05-11 2.7 Cache Copy Boundary 與 Freshness 說明快取何時只是可重建副本，何時會影響交易、權限或配額正確性。
• 2026-05-11 3.7 Event Contract 與 Replay Boundary 說明 event schema、idempotency key、replay window 與補償如何先於 broker 選型。
• 2026-05-11 5.7 Traffic、Config 與 Control Plane Boundary 說明流量、設定、secret、service discovery 與管理面如何分責任與回退。
• 2026-05-07 2.C7 Cloudflare：Cache Reserve 分層儲存快取 邊緣快取延伸到持久層以降低回源壓力的案例。
• 2026-05-07 3.C7 LinkedIn：Kafka 自動修復治理 Kafka 維運從人工處置轉向自動修復的案例。
• 2026-05-07 4.C7 Datadog：OTel 相容遷移實務 APM 採集從專有代理轉向 OTel 相容模式的治理案例。
• 2026-05-07 5.C7 Airbnb：Istio 升級治理 service mesh 升級在大規模環境下如何保持高可用。
• 2026-05-07 7.C7 Okta：BYO Telephony 的身份安全責任轉換 MFA 簡訊/語音路徑從平台托管轉向客戶自管的治理案例。
• 2026-05-01 4.7 Cardinality 治理與成本邊界 把 metric / log / trace 的 cardinality 與成本作為平台一級治理議題
• 2026-05-01 6.7 DR 演練與 Rollback Rehearsal 把回復路徑從紙面計畫變成定期可重播、可量測的驗證流程
• 2026-04-24 8.7 失敗模式審查（Failure Mode Audit） 以概念層判讀事故流程弱點，聚焦分級、指揮、回復與交接節奏
• 2026-04-23 0.7 錯誤定位、觀測訊號與備援切換設計 從錯誤分類、定位線索、降級策略與 failover 設計服務可維護性
• 2026-06-22 4.8 訊號治理閉環 把 postmortem 揭露的偵測缺口回寫成新訊號、讓觀測能力隨事故學習成長
• 2026-05-13 1.8 State Ownership 與 Query Boundary 正式狀態 vs 派生狀態的責任分層、CQRS / event sourcing / materialized view、四種 query 邊界
• 2026-05-12 9.8 效能可觀測性 saturation metric、USE / RED method、cost dashboard
• 2026-05-12 9.C8 Niantic Pokémon GO：在 GCP 上承載 50 倍突發流量 Pokémon GO 上線時實際流量達原始預估 50 倍、Google CRE 怎麼即時補容量
• 2026-05-11 2.8 Cache Data Shape 與 Access Pattern 說明 cache value、key space、資料結構與存取型態如何反映服務語意。
• 2026-05-11 3.8 Queue Consumer Retry 與 Replay Handoff（實作示範） 以 order_created consumer 示範 queue 路徑如何交付 idempotency evidence、DLQ handling、replay runbook 與 incident decision log。
• 2026-05-11 5.8 Deployment Rollout with Drain and Rollback（實作示範） 以 checkout service 示範部署切換如何交付 canary evidence、drain signal、release gate 與 incident decision log。
• 2026-05-07 2.C8 Meta：TAO 社交圖快取演進 社交圖查詢在規模化下如何把快取做成資料層能力。
• 2026-05-07 3.C8 Cloudflare：Queues 全球交付模型 事件佇列服務在全球網路下的交付語義與治理案例。
• 2026-05-07 4.C8 Airbnb：Kubernetes 規模化下的觀測訊號治理 叢集擴縮與工作負載變動如何回寫觀測模型。
• 2026-05-01 6.8 Release Gate 與變更節奏 把驗證、migration、相容性納入放行判準
• 2026-04-23 0.8 資安與資料保護需求 從權限分級、伺服器防護、資料遮罩、傳輸保護與稽核設計安全邊界
• 2026-06-22 4.9 Continuous Profiling 把 CPU / memory / lock profile 從一次性除錯升級為持續訊號
• 2026-05-27 5.9 邊緣分發與靜態資源（CDN / Origin Protection） 整理 CDN 與 edge cache 在部署平台中的責任邊界、origin protection、purge 與 invalidation 策略
• 2026-05-13 1.9 Reconciliation 與 Data Repair 資料不一致的分類、偵測模式、修復策略、audit trail、跟 backup / PITR 整合
• 2026-05-12 9.9 Performance Improvement Loop 壓測 → profile → fix → re-test → release gate 的閉環
• 2026-05-12 9.C9 Spotify：從自管 Kafka 遷移到 GCP Pub/Sub 的事件交付系統 Spotify 把自管 Kafka 事件系統遷移到 Google Cloud Pub/Sub、避免自管 broker 的容量規劃成本
• 2026-05-11 2.9 Cache Migration 與 Stampede Rollback（實作示範） 以商品詳情與價格快取示範 cache migration 如何交付 evidence package、release gate 與 incident decision log。
• 2026-05-07 2.C9 反例：快取切換引發 Stampede 回歸 快取策略切換若缺乏保護，會導致回源壓力與錯誤率連鎖上升。
• 2026-05-07 3.C9 反例：Queue 語義切換誤配 at-least-once / exactly-once 語義誤配導致資料重複與遺漏。
• 2026-05-07 4.C9 反例：OTel 遷移後訊號漂移 雙軌採集未對齊導致告警與 SLO 判讀失真。
• 2026-05-07 5.C9 反例：平台切流未先 Draining 切流時忽略連線清退造成請求錯誤與重試風暴。
• 2026-05-07 7.C9 反例：憑證輪替未分 Scope 憑證輪替若未分域分批，容易造成跨系統連鎖中斷。
• 2026-05-01 6.9 容量與成本邊界 把容量規劃跟成本約束變成驗證輸入
• 2026-05-01 8.9 事故型態庫入口 把跨服務的共通事故型態抽成型態卡，作為新事故的判讀錨點
• 2026-04-23 0.9 知識網：訊息與事件決策路徑 把 broker、queue、ack、retry、DLQ、replay 與 idempotency 串成可操作的非同步決策語言
• 2026-06-22 4.10 Client-side / Synthetic / RUM 補 server-side 看不到的 user perceived 訊號
• 2026-06-22 Cloud Monitoring Metrics Model 與 MQL 說明 GCP Cloud Monitoring 的 monitored resource / metric descriptor 模型、MQL 與 PromQL 查詢、custom metrics 設計、alerting policy 與 Managed Prometheus 整合
• 2026-06-22 CloudWatch Logs Insights 查詢與日誌治理 說明 CloudWatch Logs Insights 查詢語法、log group 設計、retention policy、cross-account aggregation、subscription filter 與 cost governance
• 2026-06-22 Datadog 成本治理與 Agent 配置 說明 Datadog 的計價模型、custom metrics 成本控制、Agent 部署配置與常見故障模式
• 2026-06-22 High-Cardinality Query Model 與 BubbleUp 說明 Honeycomb 的 event-based 資料模型、high-cardinality 查詢設計、BubbleUp 異常偵測、SLO / burn rate、derived columns、dataset 設計與 OTLP ingestion
• 2026-06-22 Index Lifecycle Management 與 Log Pipeline 說明 Elasticsearch ILM policy 設計、data stream / rollover、Beats vs Elastic Agent 採集選擇、ingest pipeline 與 shard sizing、cross-cluster 策略與 cost governance
• 2026-06-22 LGTM Stack 組合運維：Loki + Grafana + Tempo + Mimir 說明 Grafana Stack 四個元件的責任分工、部署模式、常見故障與 dashboard provisioning
• 2026-06-22 Prometheus 容量規劃與故障模式 說明 Prometheus 單機容量邊界、cardinality 與 retention 的資源模型、常見故障模式與判讀方式
• 2026-06-22 Sentry Error Grouping 與 Fingerprinting 策略 說明 Sentry 預設 grouping 演算法、自訂 fingerprint rules、merge/unmerge 操作、grouping 不準的判讀與大量 unique errors 的治理
• 2026-06-16 2.10 Pub/Sub 與即時 fan-out 說明 Redis Pub/Sub 的即時廣播責任、at-most-once 邊界，以及何時升級到 Streams 或正式 message queue
• 2026-06-16 5.10 Outbound Tunnel 入口與生命週期 整理 cloudflared / Tailscale 等反向隧道的入口形態、生命週期合約與故障模式
• 2026-06-16 OTel Collector 部署模式：agent / gateway / sidecar 與 pipeline 設計 說明 OpenTelemetry Collector 三種部署位置的責任分工、receivers/processors/exporters pipeline 設計，以及 collector 失效、記憶體壓力與 backpressure 的故障演練與容量邊界
• 2026-05-18 Cloudflare Page Shield：用 CSP + SRI + script monitoring 防 client-side supply chain Page Shield 三層防禦（CSP / SRI / script monitoring）對應 Magecart / formjacking / skimmer / 第三方 SDK 注入的不同 attack pattern、Cloudflare dashboard + API 配置、四個 production 踩雷（inline script 漏 / dynamic loader / CSP report 噪音 / SRI hash mismatch）、跟 dev workflow + WAF 整合
• 2026-05-18 HashiCorp Vault Dynamic Credential：lease 治理跟 application 整合的實作層 Vault database secrets engine 怎麼配、application 怎麼 renew lease、production 五大踩雷（lease 過期 race、DB max_connections 撞牆、Vault sealed、token expire、scope 過寬）、容量規劃跟 vault-agent injector 整合
• 2026-05-18 Kubernetes Graceful Shutdown：termination 序列跟你以為的不一樣 K8s pod termination 五步序列、preStop / SIGTERM / terminationGracePeriodSeconds 的真實時序、5 個 production 踩雷（500 期間 502、connection drain race、init container 重啟、StatefulSet 串行終止、Job 不 graceful）、跟 service mesh / readiness probe 整合
• 2026-05-18 Splunk Risk-Based Alerting：從 alert per rule 到 score-aggregated notable Splunk Enterprise Security 的 RBA 方法論：risk score / modifier / notable 三層 model、ES 配置 step-by-step、tuning playbook（false positive / score inflation / threshold drift / decay）、capacity 成本、跟 SOAR + case management 整合
• 2026-05-13 1.10 KV / Document DB 容量規劃 DynamoDB / Cosmos DB / Bigtable / MongoDB 等 KV / Document DB 的容量設計、partition key 取捨、capacity mode 選擇
• 2026-05-12 9.10 Production-Side 驗證 shadow traffic、dark launch、canary、production-like load test
• 2026-05-12 9.C10 Cloud Spanner：每秒 10 億請求的全球一致性資料庫 Google Cloud Spanner 內部峰值 10 億 req/sec、跨地區強一致 — 全球分散式 OLTP 容量參考
• 2026-05-07 2.C10 對照：規模差異下的快取策略 同一快取策略在小中大型服務下會產生不同風險。
• 2026-05-07 3.C10 對照：規模差異下的佇列模型 同一 queue 模型在不同規模下的治理與失敗邊界差異。
• 2026-05-07 4.C10 對照：規模差異下的觀測遷移 觀測遷移在不同規模團隊下的流程與風險差異。
• 2026-05-07 5.C10 對照：規模差異下的平台遷移 平台遷移策略在小中大型組織下的差異。
• 2026-05-07 7.C10 對照：規模差異下的身份治理 identity 控制面治理在不同規模服務下的失敗邊界差異。
• 2026-05-01 6.10 Contract Testing 與 Schema 演進 把跨服務 / API / event schema 的隱性期待變成可驗證契約，控制演進相容性
• 2026-05-01 8.10 Stakeholder 通訊與外部狀態頁 把 impact scope、status page、補償政策串成節奏
• 2026-04-23 0.10 知識網：容量、觀測與資安決策路徑 把容量、可觀測、備援、權限、憑證與稽核術語串成統一的服務治理語言
• 2026-06-23 Datadog OTLP Ingestion 與 OTel 整合 說明 Datadog Agent 的 OTLP receiver 配置、OTel SDK 與 Datadog SDK 的 feature parity 差異、resource attribute mapping、常見故障與成本模型
• 2026-06-23 Grafana Loki 設計與操作限制 說明 Loki 的 label-based 設計哲學、跟 Elasticsearch 的根本差異、label cardinality 限制、LogQL 查詢模式與成本模型
• 2026-06-22 4.C11 Uber：M3 大規模 Metrics 平台 從散落的 Prometheus 實例到統一 metrics 平台，處理 cardinality 爆炸、長期 retention 與跨叢集查詢的規模化挑戰。
• 2026-06-22 Cloud Logging 查詢、匯出與合規 說明 GCP Cloud Logging 的查詢語言、log router / sink 匯出架構、retention 設計、organization-level 聚合、audit log 與 PII / CMEK 合規治理
• 2026-06-22 CloudWatch Alarms 與 Composite Alarms 操作實務 說明 CloudWatch Metric Alarm、Anomaly Detection alarm、Composite Alarm 設計、alarm actions、missing data 處理與 cost 考量
• 2026-06-22 DragonflyDB → Redis / Valkey：回退到標準生態的遷移路徑 從 DragonflyDB 遷回 Redis 或 Valkey，處理 snapshotting → RDB/AOF 差異、HA 架構切換與 Cluster mode 重建的階段化流程
• 2026-06-22 KeyDB → Redis / Valkey：從多線程 fork 回歸主線的遷移路徑 從 KeyDB 遷回 Redis 或 Valkey，處理 active-active replication 拆除、多線程 → 單線程效能差異、FLASH storage 移除與 Sentinel/Cluster 對齊
• 2026-06-22 PromQL 與 Recording Rules 實務 說明 PromQL 常見查詢模式、recording rules 設計慣例、SLI 表達式寫法與效能陷阱的判讀方式
• 2026-06-22 Sentry Release Tracking 與 Session Replay 說明 Sentry release health、deploy tracking、session replay 隱私設定、performance monitoring 與 OTel 整合、self-hosted vs SaaS 取捨
• 2026-06-20 Rate Limit 實作 單機 middleware / Redis 分散式限速 / 配額設計 — 概念見 DevOps 流量管控，本章聚焦後端實作
• 2026-06-17 7.C11 選型：單人遠端 Shell — Tailscale vs Cloudflare Tunnel 以「手機遠端操作本機 shell」為情境，比較 Tailscale mesh VPN 與 Cloudflare Tunnel + Access 兩種存取模型的選型判讀。
• 2026-06-16 2.11 Redis data types 實作 說明 sorted set、bitmap、HyperLogLog、counter 與 hash 各自承擔的服務語意、容量行為與原子性邊界
• 2026-06-16 AWS ElastiCache 的責任邊界：managed 接手了什麼、又默默留下什麼 ElastiCache 把 failover、patching、snapshot、跨 AZ 複製接走，但 cache stampede、client 重連、key 設計、eviction policy 還是你的事。本文用 shared responsibility 拆解 managed 的真實邊界、展開 engine 選擇與 cluster mode 配置、5 個把『以為 AWS 全包』寫成事故的 production 踩坑，以及 ElastiCache 到 MemoryDB 的 durability 邊界
• 2026-06-16 AWS SQS → Google Pub/Sub：queue 模型搬到 topic + subscription 模型的跨雲遷移 SQS 是單一 region-scoped pull queue、Pub/Sub 是 global topic + first-class subscription 的 pub/sub 模型；這篇跨雲 migration playbook 走 6 維 diff dimension audit（components / data topology 軸 High）、對位 visibility timeout → ack deadline、maxReceiveCount → dead-letter topic、long polling → streaming pull、IAM policy → Service Account、SQS-to-many-consumer 要重設計成 topic fan-out；含 5 個 production 故障演練（fan-out 行為差 / ack deadline 太短重投 / ordering key vs FIFO / 跨雲網路成本 / DLT 設定差）跟 dual-publish 漸進 cutover
• 2026-06-16 Caffeine + Redis 兩層 cache：搭起來很容易，跨實例失效才是全部的問題 L1 Caffeine（process-local）+ L2 Redis（共享）的兩層 cache 程式碼三十行就寫完，但每個 JVM 實例有自己的 L1 副本、一個實例更新不會通知其他實例——跨實例 invalidation 才是這個架構的全部難度。本文展開兩層讀寫路徑、用 Redis pub/sub 廣播失效、5 個把 L1 stale 與 GC 寫成事故的 production 踩坑，以及哪些資料適合放 L1
• 2026-06-16 DragonflyDB shared-nothing 多核架構：用 scale-up 取代 Redis Cluster Redis 要靠 Cluster 分片才能用滿一台多核機器，DragonflyDB 賭的是相反方向——單一進程 thread-per-core、shared-nothing、把單機推到 Redis 要好幾個 shard 才達到的規模。本文展開 thread-per-core 與 dashtable 的架構、fork-less snapshot、5 個把架構假設寫成 production 事故的踩坑，以及 scale-up 撞牆該回 Cluster 的邊界
• 2026-06-16 Google Pub/Sub push vs pull：不是實作偏好，是下游容量的判讀 Pub/Sub 的 push 與 pull subscription 常被當成實作偏好二選一，但它其實是一個容量判讀：push 把流量瞬間打到 endpoint，pull 讓 consumer 自己節流。下游有 RPS 限制就只能 pull。本文展開 subscription 模型、ack deadline、flow control 與 dead-letter topic，5 個把 push/pull 與 ack deadline 寫成下游打爆與重投的 production 踩坑
• 2026-06-16 Kafka Consumer Group Rebalance 與 Lag 診斷：從 protocol 到故障演練 Kafka consumer group 的 rebalance protocol（eager vs cooperative incremental）、static group membership、session.timeout.ms / max.poll.interval.ms / heartbeat.interval.ms 三個 timeout 的職責、consumer lag 均勻分布 vs 集中單一 partition 的診斷路徑、rebalance storm 成因與對策；含 kafka-consumer-groups.sh 實機驗證輸出與 4 個 production 故障演練
• 2026-06-16 KeyDB active-active 多主複製：last-write-wins 會默默吃掉哪一筆寫入 KeyDB 的 active-active 讓兩個 master 都能寫、互相同步，聽起來解決了跨區寫入的所有問題——直到兩邊同時寫同一個 key，last-write-wins 默默丟掉其中一筆。本文展開 active-active 的複製機制與衝突語意、實機驗證雙向同步、5 個把多主複製寫成資料遺失與迴圈的 production 踩坑，以及哪些資料能放 active-active、哪些不能的邊界
• 2026-06-16 Memcached slab allocator 與記憶體經濟學：明明有記憶體卻在 evict Memcached 用 slab allocator 預切記憶體成固定大小的 chunk，這讓它永不碎片化、卻會在還有大量空閒記憶體時就開始淘汰——slab calcification。本文展開 slab class、growth_factor、page 分配的會計模型、5 個把 slab 機制寫成記憶體浪費與淘汰事故的 production 踩坑，以及純 KV 邊界與多執行緒擴展的判讀
• 2026-06-16 NATS core 到 JetStream：fire-and-forget 在哪裡不夠、跨過去要付什麼 Core NATS 的 fire-and-forget 在 consumer 重啟或 rolling deploy 時掉訊息——這不是 bug、是設計。需要訊息不丟就跨進 JetStream（persistence + at-least-once + redelivery）。本文展開 core 與 JetStream 的邊界、stream 與 consumer 的求值模型、實機驗證的 durable pull consumer、5 個把 JetStream consumer 寫成丟訊息與重投風暴的 production 踩坑
• 2026-06-16 Pub/Sub Ordering Key、Dead-Letter Topic 與 Schema Enforcement：三道交付治理 Pub/Sub overview 之下的 implementation-layer deep article — 把 ordering key 的有序代價、dead-letter topic 的 poison message 隔離、schema enforcement 的契約守門三件事寫到可操作：subscription 是 first-class、ackDeadline 與 extension、push vs pull vs streaming pull + flow control、Avro / Protobuf schema、Pub/Sub Lite 與標準版差異、BigQuery / Cloud Storage subscription，含 5 個 production 故障演練（ordering 限流 / ack deadline 太短重投 / DLT max delivery attempts / push 500 retry storm / schema 擋下不相容 publish）
• 2026-06-16 RabbitMQ → Kafka：從『處理即承諾』到『寫入即承諾 + 可 replay』的 paradigm shift RabbitMQ 跟 Kafka 不是同類產品（work queue vs event streaming log）、把 work queue 直接搬成 topic 會踩 paradigm 落差；本文先跑 6 維 diff dimension audit（paradigm 跟 data topology 差最大）、釐清什麼 workload 真該遷什麼不該、再展開 application 重設計的 5 個踩雷（manual ack 觀念帶到 offset commit / routing key → partition key 的 ordering 邊界 / DLX → 自建 DLQ topic / prefetch → max.poll.records / 即刪 vs retention 的 replay 差異）、以及 dual-write / shadow consume 漸進 cutover 與長期混合架構
• 2026-06-16 RabbitMQ DLQ 與分層 retry：別把失敗訊息 requeue 回隊首 RabbitMQ 處理失敗訊息最常見的錯是直接 requeue 回原隊列——它回到隊首、反覆失敗、把後面的訊息全卡住（head-of-line blocking）。正解是用 dead-letter exchange + TTL 組出 work → delay → DLQ 的分層 escalation。本文展開 DLX 求值模型、實機驗證的三層拓樸、5 個把 retry 寫成無限迴圈與隊列阻塞的 production 踩坑，以及 retry 拓樸的容量邊界
• 2026-06-16 Redis → Valkey：同一份程式碼、不同授權的 drop-in 遷移 Valkey 是 Redis 7.2.4 的 fork，bit-for-bit 幾乎同源、RDB/AOF 檔案相容、client 一行不改——這是技術上最容易的 cache 遷移。真正的工作不在搬資料，在授權合規驗證與 fork 後分歧（Redis 7.4+ 功能、Stack 商業 module）的盤點。本文走 Type B drop-in、相容性 audit 前置、5 個把『最容易的遷移』寫成事故的踩坑
• 2026-06-16 Redis Streams → Kafka：從 embedded stream 長成 dedicated event streaming Redis Streams 是 Redis 生態內的 append-only log data structure、Kafka 是專用 distributed event streaming platform；這趟遷移是 paradigm shift — 從 RAM-bound 單 stream key 換成 partition + log retention 的多節點系統。本文先用 Arcjet 反向案例點明多數中小規模 Redis Streams 就夠、不該為流行遷 Kafka、再講真的該遷的訊號（retention 超出 RAM 成本 / 長期 replay / consumer group 規模超出單 Redis）、XADD/XREADGROUP/XACK/MAXLEN/XCLAIM 的對位、retention 成本翻轉與 PEL→offset 誤用的故障演練、漸進 cutover
• 2026-06-16 Valkey 相容性驗證與 io-threads 調校：drop-in 切換與多執行緒的實機判讀 Valkey 跟 Redis 100% 相容這句話要怎麼驗證、切換才敢上線。本文用 INFO server 的雙版本回報拆解相容性的真實邊界、展開 Valkey 8 的 io-threads 多執行緒調校、5 個把 drop-in 切換或執行緒配置寫成事故的 production 踩坑，以及相容性撞牆該怎麼判斷的邊界
• 2026-06-16 從 Firestore 遷往自建 relational：撞牆驅動的 Type E 重建模、存取模型反轉與並行期 Firestore → 自建後端 + relational 不是匯資料而是反轉存取模型：client 直連變 API 中介、Security Rules 授權變後端授權、document 反正規化變正規 schema、realtime listener 與 offline 同步要重建；本文走 Type E paradigm shift 結構、展開為何字面遷移不成立、哪些該遷哪些先留、dual-write + shadow read 階段化與遷出代價判讀
• 2026-05-19 Docker Swarm → Kubernetes：5 個 Swarm production cluster 撞牆數據 Docker Swarm → Kubernetes 是 Type E paradigm shift — Swarm「simpler container orchestration」設計上限在 100-200 service 規模、跨 application 服務治理時 paradigm 不足；本文用 5 個 production cluster 量化數據開頭、5 個 production 踩雷
• 2026-05-19 DynamoDB Strongly Consistent → Eventually Consistent：same protocol, different contract DynamoDB consistency model 從 strongly consistent read 改 eventually consistent read 是 50% cost 優化但風險集中在 application contract — 同 vendor / 同 protocol / 同 table / 不同 read consistency；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 提出的 consistency axis 候選；涵蓋 read pattern audit / 5 個 production 踩雷
• 2026-05-19 Kafka ↔ NATS：不是 migration、是 messaging paradigm 重設計 Kafka 跟 NATS 不是同類產品（log-based event streaming vs subject-based messaging）、'migration' 字面上不成立；本文釐清兩家 paradigm 邊界、什麼情境真的能換、application 模式重設計的 5 個踩雷（consumer offset 觀念差 / retention model / exactly-once 假設 / schema registry 缺位 / fan-out 模式差）、跟 JetStream 對位 + 混合架構
• 2026-05-19 MongoDB → Atlas：Atlas 不是 MongoDB + managed、是另一個 product Atlas 號稱「MongoDB managed」但 operational model 完全不同（auto-scaling / VPC peering / IAM-driven access / 內建 backup / billing 模型）；本文採用 Type C operational redesign hybrid 結構、4-phase operational migration + drop-in cutover、5 個 production 踩雷（連線數限制 / IP whitelist / backup retention / IAM token 過期 / billing 暴漲）
• 2026-05-19 MySQL → PostgreSQL：從 SQL dialect diff 跑出來的 Type A 6-phase migration MySQL → PostgreSQL 是 Type A 高 schema 差 migration 的標準形態 — SQL dialect / collation / case sensitivity / replication 模型差異主導；用 pgloader / AWS DMS / 自管 dual-write 三條 path、5 個 production 踩雷（auto_increment vs SERIAL / charset 跟 collation / case sensitivity / index syntax / triggers）
• 2026-05-19 New Relic → Datadog：APM schema 對位 + agent 替換 + dashboard 重建 New Relic → Datadog 是 Type A schema diff migration — APM schema / NRQL ↔ Datadog query / agent / dashboard 全要對位；本文涵蓋 6-phase phased translation + 5 個 production 踩雷（NRQL 不直接對位 / synthetic alert 重建 / 計費模型反轉 / dashboard 自動轉失敗 / cross-platform metric 命名）
• 2026-05-19 Self-managed Prometheus → Grafana Cloud Metrics：feature × ops × cost 對照 Self-managed Prometheus → Grafana Cloud Metrics (Mimir-backed) 是 Type C operational redesign — Prometheus query API 完全相容、operational stack (HA / retention / scaling) 全託管；本文用 feature / ops / cost 三維對照表開頭、5 個 production 踩雷
• 2026-05-19 Sentry → Honeycomb：trace 不是 error、是不同 observability paradigm Sentry → Honeycomb 是 paradigm shift — Sentry 主軸是 error tracking + transaction trace、Honeycomb 主軸是 high-cardinality wide-event observability；本文釐清 paradigm 邊界、5 個 production 踩雷（event schema 對位 / sampling 行為 / error grouping 失效 / cost 模型差 / alert paradigm shift）
• 2026-05-19 Terraform → OpenTofu：HCL 跟 state file 級 drop-in、CI runner 切 binary 完成 OpenTofu 是 Terraform 在 BSL license 後的 fork、Terraform 1.5.x baseline 完全相容（HCL / state / provider）；本文是 Type B drop-in migration 的標準形態 — 用 code-led HCL / state diff sample 開頭、5 個 production 踩雷（provider version drift / state lock 微差 / Terraform Cloud feature 不支援 / CI binary name 假設 / registry routing）
• 2026-05-18 3.C11 Pinterest：Kafka tiered storage broker-decoupled Pinterest 採 broker-decoupled tiered storage、把 ~200 TB/day 熱資料卸到 S3、broker 不再是熱路徑。
• 2026-05-18 PostgreSQL Patroni HA：從 leader 失聯到 client 重連的 5 段 failover lifecycle Patroni 把 PostgreSQL HA 拆成 detection / election / promotion / reconfiguration / recovery 五段 lifecycle、每段都有獨立配置跟 failure mode；DCS quorum + watchdog 防 split-brain、async/sync replication 取捨、5 個 production 踩雷、跟 PgBouncer / HAProxy / cert-manager 整合
• 2026-05-18 Splunk → Elastic Security Detection Rule Migration：6 段 phased playbook 跟 5 大踩雷 從 Splunk Enterprise Security 遷到 Elastic Security 的 detection rule translation playbook：SPL ↔ KQL/ES|QL schema 對位、AI-assisted translation pipeline、parallel run 比對、cutover routing、5 個 production 踩雷（macro 沒對應 / time zone 差異 / summary index 不對位 / alert dedup key 衝突 / 過早 decommission）、capacity / cost 對照
• 2026-05-13 1.11 全球分散式 OLTP Spanner / Aurora DSQL / Cosmos DB multi-region write / CockroachDB / TiDB 的全球一致性取捨
• 2026-05-12 9.11 高峰事件準備 活動、季節性流量、推廣事件的 capacity readiness 流程
• 2026-05-12 9.C11 Minecraft Earth：Azure Cosmos DB 上的全球分散式 AR 遊戲 Minecraft Earth 用 Cosmos DB 跨地區分散、測試到 100 萬 RU/s 仍維持承諾延遲
• 2026-05-07 Google：Error Budget 政策如何決定發布節奏 把 SLO 消耗量轉成 release gate，讓可靠性與交付速度共用同一套決策語言。
• 2026-05-07 Slack：2022 連線恢復與狀態通訊節奏 在通訊平台自身失效時，如何同步恢復節奏與對外狀態揭露。
• 2026-05-01 4.11 Telemetry Pipeline 架構 把 log / metric / trace 的 agent → collector → ingest → storage → query 分層治理
• 2026-05-01 6.11 Migration Safety 與 DB Rollout 把 schema migration 從一次性事件變成可逆、可漸進的 rollout 流程
• 2026-05-01 8.11 Observability / Reliability / Incident Response 閉環 把 04 / 06 / 08 三個模組的雙向反饋串成可判讀循環，定義閉環健康度判讀訊號
• 2026-04-24 0.11 攻擊者視角（紅隊）：跨服務弱點判讀總表 用攻擊面、可觀察訊號與失敗代價，建立 backend 選型前的弱點盤點框架
• 2026-06-22 4.C12 Cloudflare：內部觀測平台的三層能力 全球 300+ edge 節點的觀測架構，把 monitoring、analytics 與 forensics 拆成三個獨立能力層。
• 2026-06-22 ElastiCache → 自管 Redis / Valkey：脫離 managed 的遷移路徑 從 AWS ElastiCache 遷移到自管 Redis 或 Valkey，處理 RDB export、DNS 切換、IAM 認證移除與監控重建的階段化流程
• 2026-06-22 Kafka → Google Cloud Pub/Sub：從 partition 到 topic-subscription 的模型轉換 從 Apache Kafka 遷移到 Google Cloud Pub/Sub，處理 partition → topic 模型轉換、ordering 語意差異、consumer group → subscription 對應、offset → ack deadline 切換的階段化流程
• 2026-06-22 Remote Write 與長期儲存整合 說明 Prometheus remote write 的配置、三家長期儲存後端比較（Mimir / Thanos / Cortex）、故障模式與容量規劃
• 2026-06-16 AWS SQS：Visibility timeout、long polling 與 Lambda event source 的成本與失敗形狀 SQS deep article：visibility timeout 對齊 consumer 處理時間（ChangeMessageVisibility）、long vs short polling 的 cost 取捨（WaitTimeSeconds）、SQS + Lambda event source mapping（batch size / batch window / 並行 ramp-up）、DLQ + redrive policy（maxReceiveCount）、message size 與 extended client、per-request cost 模型；含 5 個 production 故障演練（VT < 處理時間 redelivery、polling 設定省成本、Lambda 部分失敗整批重投、DLQ maxReceiveCount、FIFO 吞吐上限）
• 2026-06-16 Firestore Security Rules 授權建模與可測試化：把規則當程式碼治理 Firestore client 直連模型把整個授權控制面壓在 Security Rules 這套 DSL 裡；本文展開規則的求值模型、把授權拆成可組合 function、用 emulator 寫單元測試、五個把規則寫成資安漏洞的 production 踩坑，以及規則複雜度撞牆時把授權拉回後端的邊界
• 2026-06-16 Kafka Replication、ISR 與 exactly-once：從 acks 到端到端不重不漏 Kafka 的可靠性由 replication 與 ISR 決定寫入承諾、由 producer idempotence 與 transaction 決定處理語義。本文涵蓋 acks=0/1/all 取捨、min.insync.replicas 與 ISR shrink/expand 的真實行為、enable.idempotence 去重、Kafka transaction + read_committed 隔離、以及端到端 exactly-once 的邊界與成本；含 3-broker 叢集停 broker 觀察 ISR 收縮到低於 min.insync 後 acks=all 被拒的實機演練。
• 2026-06-16 NATS JetStream 設計與 supercluster / leaf node：stream、consumer、跨區拓樸與多租戶 NATS JetStream 的 implementation-layer deep article：stream 設計（storage / retention / discard / 容量上限）、consumer 設計（pull/push、explicit ack、AckWait、MaxDeliver、replay）、Cluster Raft / Supercluster gateway / Leaf node edge 三層拓樸、subject-based ACL 多租戶；含 4 個 production 故障演練（AckWait 太短重投、discard policy 選錯丟訊息、leaf node 斷線重連、stream replica 失去 quorum）。
• 2026-06-16 RabbitMQ → AWS SQS：交出 broker 維運、把 routing 收斂進 application 自管 RabbitMQ 叢集遷到 AWS SQS 是 operational redesign：protocol 不相容、application 要從 manual ack 改成 visibility timeout + delete、exchange routing 收斂成 SNS fan-out 或多 queue；本文跑 6 維 diff dimension audit（operational 差最大）、釐清什麼該遷什麼不該遷、5 個 production 故障演練（DLX → redrive policy / prefetch → batch + visibility / fan-out → SNS-to-SQS / 256KB 大小限制 / ordering 到 FIFO 的吞吐取捨）跟漸進 cutover
• 2026-06-16 Redis Streams XCLAIM / PEL 失敗接管與 Cluster 影響 Redis Streams 把可靠性責任放在 application 層：PEL 記錄已投遞未 ack 的訊息、XCLAIM / XAUTOCLAIM 是 consumer crash 後唯一的接管機制。本文用實機輸出走 PEL / XACK / XCLAIM / XAUTOCLAIM / min-idle-time 機制、5 個故障演練（PEL 卡死、搶單、MAXLEN 修掉未 ack 訊息、Cluster 單 shard 限制、failover 後 PEL 狀態），跟 MAXLEN / XTRIM retention 取捨。
• 2026-05-19 Datadog → Grafana Stack：把 $50K/month bill 拆解到 self-hosted observability Datadog 五層計費（host APM / metric / log ingest / log retention / RUM）拆解、對位 Grafana Stack（Mimir / Loki / Tempo / Grafana / Alloy）的 5 層責任；OTel-based agent migration、5 個 production 踩雷（cardinality 爆 / log volume cost / dashboard 不直接轉 / alert routing 換邏輯 / SLO definition 差異）、cost reality check
• 2026-05-19 etcd → Consul：KV + N 個 extras feature matrix etcd → Consul 是 Type E paradigm shift expansion — 從 pure KV store 升到 service mesh / discovery / health check / multi-DC；本文用對照表 + paradigm expansion 路線、5 個 production 踩雷（API 對位 / lock semantics / watch event model / multi-DC topology / ACL system）
• 2026-05-19 Jenkins → GitHub Actions：Pipeline 5 段 lifecycle 的對位 + 翻譯 Jenkins → GHA 是 Type A 高 schema 差 migration、主軸是 Groovy DSL → YAML workflow 翻譯；本文按 pipeline 5 段 lifecycle（source → build → test → scan → deploy）逐段對位、5 個 production 踩雷（shared library equivalence / ephemeral workspace / plugin gap / self-hosted runner / matrix build 表達差）
• 2026-05-19 MongoDB Shard Expansion + Multi-DC：Type F「不需要 parallel run」的 multi-region 例外 MongoDB sharded cluster 加 shard + 跨 DC expansion 是 Type F「topology re-layout」第 3 個 dogfood — 同時改 sharding + replication topology + region distribution；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 第 3 點「Type F 不需要 parallel run」claim 的例外（multi-region rollout 必須 parallel run + 切流量）；涵蓋 chunk migration / replica set add member / cross-DC routing
• 2026-05-19 MySQL Replication Topology：async / semi-sync / GTID 不是三選一、是三個 trade-off 軸的疊加 MySQL replication 不是「選 async 還是 semi-sync」、是 *durability / latency / consistency* 三個 trade-off 軸的疊加；GTID 是跨 mode 的 infrastructure layer、不是第三種 mode。本文走 3 軸取捨模型 → async / semi-sync 行為對比 → GTID 替代 binlog-position 的好處 → 配置 step-by-step → 5 production 踩雷（lag 暴衝 / semi-sync 退回 async / GTID gap / Loss-Less semi-sync 真的 loss-less / chained replication 雪崩）→ 跟 Aurora MySQL / Vitess / ProxySQL / Orchestrator 整合
• 2026-05-19 PostgreSQL Replication Topology：async / sync / quorum 三模式跟 LSN + replication slot 的三軸組合 PostgreSQL streaming replication 不是「sync 或 async」、是 *durability / latency / consistency* 三軸組合 + LSN-based 進度追蹤 + replication slot 治理。本文走 3 軸取捨模型、async / sync / quorum-based sync 行為對比、LSN + replication slot 機制、配置 step-by-step、5 production 踩雷（standby lag 暴衝 / sync standby 退回 async / orphan replication slot / cascading replication 雪崩 / failover 後 timeline 分歧）、跟 Patroni HA + logical replication 整合
• 2026-05-19 Redis → DragonflyDB：drop-in 相容下的容量躍升 + 5 個踩雷 DragonflyDB 號稱 Redis drop-in 替代、單機 throughput 25x、記憶體效率 30% 提升；遷移流程簡單但有 5 個 production 踩雷（RDB 版本差 / Lua 腳本不全支援 / Pub-Sub fanout 行為差異 / Cluster mode 兼容度 / Modules 不支援）、跟 Sentinel / Cluster 模式對位
• 2026-05-19 Self-managed ELK → Elastic Cloud：5 年 ELK 集群的 lifecycle 收尾 Self-managed ELK Stack → Elastic Cloud 是 Type C operational redesign — protocol drop-in、operational stack（cluster sizing / shard 治理 / upgrade / backup）全託管；本文按 5 年 ELK lifecycle (build → scale → degrade → save → migrate) 組織、5 個 production 踩雷
• 2026-05-19 Self-managed Kafka → AWS MSK：把 $15K/month operational cost 拆解到 managed Kafka self-managed → MSK 是 Type C operational redesign — protocol 完全相容、operational stack（ZooKeeper / brokers / monitoring / patching）全託管；本文用 cost 拆解開頭、5 個 production 踩雷（client connection pattern / version pinning / metric pipeline / IAM auth / cross-cluster mirror）
• 2026-05-19 Vault → AWS Secrets Manager：「secret」不是「secret」、identity model 才是核心差異 Vault → AWS Secrets Manager migration 表面是 secret store 替換、實際核心是 identity model 對位（Vault token + policy vs AWS IAM + resource policy）；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 提出的 identity axis 候選 — identity 是否獨立 audit 軸；5 個 production 踩雷（IAM principal 對位 / dynamic credential 對等失敗 / lease lifecycle 模型不同 / audit log 結構差 / 計費模型反轉）
• 2026-05-18 3.C12 Pinterest：Shallow Mirror 優化 MirrorMaker Pinterest 跨 3 region MirrorMaker、原版解壓+重壓造成 CPU/memory 2-10x spike、改 RecordBatch 層淺迭代。
• 2026-05-13 1.12 大規模 DB 遷移實戰 跨 DB 遷移的 dual-write、[shadow read](/backend/knowledge-cards/shadow-read/)、cutover、rollback 流程 — 從實戰案例提煉的工程做法
• 2026-05-12 9.12 SLO 與 Performance Budget performance budget 跟 SLO / error budget 的對接
• 2026-05-12 9.C12 Riot Games：246 個 EKS cluster 的多遊戲多地區治理 Riot Games 從 Mesos 遷移到 EKS、用 246 個 cluster 跨遊戲跨地區治理、年省 1000 萬美金
• 2026-05-07 Google：Postmortem Action Item Closure 治理 把 blameless postmortem 從會議文件變成可追蹤的可靠性治理機制：action item 分級、完成條件與回寫節奏。
• 2026-05-02 0.12 觀測、可靠性與事故服務選型 從訊號、驗證與響應三層能力判斷操作控制服務的選型順序
• 2026-05-01 4.12 Audit Log 邊界與 PII 治理 把稽核訊號從 operational log 拆出、按法規與不變性治理
• 2026-05-01 6.12 Idempotency 與 Replay 驗證 把重試、重播與冪等性從口頭約定變成可驗證屬性
• 2026-05-01 8.12 IC Handoff 與長事故跨班次協調 把 24h+ / 跨 timezone 事故的接班節奏變成可重複流程
• 2026-06-22 4.C13 Discord：從儲存問題回推觀測缺口 每次儲存遷移都暴露觀測盲區，把儲存成長問題重新框架為訊號設計問題。
• 2026-06-16 Firestore 高頻寫入與 distributed counter：單 document contention 邊界與分片計數 Firestore 單一 document 有持續寫入的軟上限、高頻計數寫爆 contention 是常見事故；本文展開寫入 contention 的成因、distributed counter 分片計數的實作與讀取彙總、shard 數量與讀寫成本的取捨、五個高頻寫入踩坑，以及計數需求超過分片能處理時改走外部聚合的邊界
• 2026-06-16 Kafka Retention 與 Tiered Storage：保留策略、log compaction 與冷熱分層 Kafka 的保留策略決定 replay window 與儲存成本：retention.ms / retention.bytes 控制刪除邊界、cleanup.policy 切換 delete 與 compact、log compaction 用最新值取代歷史、tiered storage 把冷資料卸到 S3 讓 broker 容量與保留期解耦。本文涵蓋配置實機驗證、4 個故障演練（replay 失敗 / compaction 不回收磁碟 / cold tier 讀延遲 / retention.bytes 提早刪）、容量成本與整合路由。
• 2026-06-16 RabbitMQ Queue Type 選型：Classic、Quorum、Stream 的責任邊界與容量取捨 RabbitMQ 3.x 三種 queue type 的選型 deep article — classic queue（mirrored 已 deprecated）、quorum queue（Raft 一致性、取代 mirrored）、stream（3.9+ append-only log、可重複消費）。涵蓋三種模型在 throughput / retention / replay / 記憶體成本的判讀、宣告語意差異（實機驗證）、4 個 production 故障演練（mirrored 網路放大 / quorum loss / stream retention 超量 / classic→quorum in-flight message），與容量規劃。
• 2026-05-27 1.13 應用層查詢反模式與 Query 預算 整理 N+1、select *、缺索引、ORM lazy load、long transaction 等查詢反模式與每請求的 query 預算判讀
• 2026-05-27 9.13 擴展軸與 Stateless 前提 整理垂直 / 水平擴展取捨、stateless vs stateful 前提、auto scaling 操作模型與兩種擴展的 hidden cost
• 2026-05-19 MySQL Online Schema Change：gh-ost 跟 pt-online-schema-change 兩條完全不同的 ghost table 路徑 MySQL ALTER TABLE 可能鎖整張表，production 需要 online schema change 流程。gh-ost（GitHub）跟 pt-online-schema-change（Percona）都用 ghost table 解決、但底層機制完全不同：pt-osc 用 trigger 同步、gh-ost 用 binlog stream 同步。本文走兩工具機制對照表 → trigger vs binlog 各自取捨 → 配置 step-by-step → 5 production 踩雷（trigger overhead / binlog 延遲 / FK constraint / hot trigger lock / 切換瞬間 deadlock）→ 何時用哪一個
• 2026-05-19 PostgreSQL Online Schema Change：先用 ALTER 內建特性、不能解才 pg_repack / pg-osc PostgreSQL ALTER TABLE 對多數變更已是 *fast catalog-only*（add column nullable / drop column / 改 default），不必走 ghost table tool。本文走 PG 內建 fast DDL 行為、何時必須走 pg_repack / pg-osc、兩工具機制對比（trigger-based vs WAL-shipping）、配置 step-by-step、5 production 踩雷（lock 升級 / VACUUM FULL 誤用 / pg_repack version mismatch / concurrent index 失敗清理 / generated stored column 不能 online）、跟 MySQL gh-ost / pt-osc sibling 對比
• 2026-05-19 Redis → Memcached：Memcached 不是 simpler Redis、是 cache paradigm Redis → Memcached 是 Type E paradigm reduction migration — 從 multi-paradigm（KV + 資料結構 + pub/sub + Lua + streams）退到 pure cache；不是「remove Redis features」、是「重新分配 Redis-specific feature 到對應 specialized 服務」；5 個 production 踩雷 + paradigm reduction 路線
• 2026-05-19 Redis Cluster Re-sharding：source = target，但 topology 重劃的 5 段流程 Redis cluster re-sharding 是 5 type migration 漏類實證 — source / target 同 cluster、無 schema / paradigm 差、但 16384 slot 重分配是核心；本文涵蓋 4 種 re-sharding driver、slot migration 機制、redis-cli --cluster rebalance / reshard 工具、5 個 production 踩雷（cluster busy / replica lag / client cache stale / cross-slot transaction / monitor gap）
• 2026-05-18 3.C13 Shopify：Debezium CDC over sharded MySQL Shopify 100+ MySQL shard、150 Debezium connector、Black Friday 100K records/sec P99 < 10s。
• 2026-05-12 9.C13 Disney+ Hotstar：IPL 板球決賽 1860 萬人同時直播 Hotstar 在 IPL 板球決賽創下 1860 萬同時觀看的全球直播紀錄、CDN 與全球邊緣容量極限
• 2026-05-07 0.13 操作控制 vertical slice 實作入口 用一個服務串起觀測證據、可靠性驗證、事故決策與回寫閉環
• 2026-05-07 Google：Toil Budget 與 Automation 投資政策 把 toil 從感受問題轉成預算問題：用時間配比與自動化回報機制，避免 on-call 壓力長期侵蝕可靠性工程。
• 2026-05-01 4.13 Service Topology 與 Dependency Map 把跨服務依賴從文件變成自動發現的觀測訊號
• 2026-05-01 6.13 Performance Regression Gate 把效能 baseline 從一次性壓測變成持續對齊的 release gate，涵蓋 baseline 設定、判讀方法、variance 控制與退化定位
• 2026-05-01 8.13 Repeated Incident 與 Toil 治理 把同型事故反覆發生與重複手動修復作為工程化治理對象
• 2026-06-22 4.14 Anomaly Detection 把 ML / statistical baseline 訊號跟 rule-based alert 整合
• 2026-06-22 4.C14 觀測平台成本治理：從帳單驚嚇到可預測成本 觀測帳單持續超線性成長時，用 cost attribution、cardinality budget、log tiering 跟 adaptive sampling 建立可預測成本模型。
• 2026-06-16 Firestore document 反正規化與一致性維護：fan-out write、副本同步與資料修復 Firestore 沒有 JOIN，查詢能力逼著把關聯資料反正規化複製多份；本文展開反正規化的建模決策、fan-out write 維護副本一致、batch 與 transaction 的選擇、五個副本不一致的 production 踩坑，以及反正規化複雜到該回關聯式的邊界
• 2026-06-16 Kafka Schema Registry 與 schema 演進：wire format、compatibility level 與安全演進規則 Kafka 跨系統事件總線的 schema 治理 implementation deep article — Schema Registry（Confluent / Apicurio）角色、Avro / Protobuf / JSON Schema 取捨、subject naming strategy、backward / forward / full / none 及其 transitive 版本、producer 帶 schema ID 的 5-byte wire format、加欄位帶 default 與刪欄位分步的安全演進規則；含 4 個 production 故障演練與實機驗證的 REST API 回應
• 2026-06-16 RabbitMQ Network Partition 與 Cluster 一致性：腦裂下要保誰 RabbitMQ Erlang cluster 在 network partition 下的行為與處置 — disc/ram node 拓樸、cluster_partition_handling 三策略（ignore / pause_minority / autoheal）的可用性與一致性取捨、腦裂偵測機制、quorum queue 在失去 quorum 時的 Raft 行為。含 3-node OrbStack 實機演練（pause_minority 暫停少數派、quorum queue 失去 quorum 後寫入阻塞、classic queue 同情境續寫對照）。
• 2026-06-16 Redis 記憶體與淘汰調校：maxmemory-policy、LFU 與碎片化的實戰判讀 Redis 的記憶體是一條會在半夜爆掉的曲線：maxmemory 設多少、policy 選 LRU 還 LFU、碎片化什麼時候開始吃掉 30% RAM、OOM 時 noeviction 怎麼讓寫入全部失敗。本文展開 Redis 記憶體會計模型、eviction policy 的選型判讀、5 個把記憶體配置寫成 production 事故的踩坑，以及單機記憶體撞牆後該往 cluster 還是 DragonflyDB 走的邊界
• 2026-05-27 1.14 Production Slow Log Closed Loop 把 production slow log 從『偶爾看一下』變成『定期審視 + PR review 整合 + regression 偵測』的閉環、補 1.13 反模式清單後的操作層
• 2026-05-27 9.14 連線池放大解法（PgBouncer / RDS Proxy / ProxySQL） 水平擴展應用層時 DB 連線池放大問題的具體解法、connection pooler 三大選項對比、解 9.13 提出但未深入的隱性成本
• 2026-05-19 MySQL ProxySQL 配置：connection / query / route / response 四段 lifecycle 跟 query rule 設計 ProxySQL 是 MySQL 生態的 connection pool + query routing 標準。本文走 connection → query parse → route → response 四段 lifecycle、query rule engine 的 rule chain 設計、Hostgroup / Server / User 三層 schema、配置 step-by-step（讀寫分離 + replica lag-aware routing）、5 production 踩雷（query rule 順序錯亂 / connection 漂移 / write 路由到 replica / runtime / disk schema drift / mirror traffic 副作用）、跟 Replication / Orchestrator / HAProxy 整合
• 2026-05-19 PostgreSQL Connection Scaling：process-per-connection model 跟為什麼 pooler 是必裝 PG 每個 client connection fork 一個 backend process（不是 thread）、RAM 成本 5-15MB/connection、context switch 跟 fork() cost 在 100+ connection 後線性放大、所以 pooler 不是 *optional optimization* 而是 *production prerequisite*。本文走 process-per-connection model 跟 MySQL thread-per-connection 對比、max_connections + shared_buffers + work_mem 三 GUC 互動、application-side pool vs middleware pool vs RDS Proxy 三層選擇、5 production 踩雷（connection storm / fork() cost 在 burst 流量 / shared_buffers 跟 connection 數壓縮 / double-pool 配置錯誤 / max_connections 設太大反而慢）、跟 PgBouncer config 互補不重複
• 2026-05-18 3.C14 Yelp：Schematizer 自建 Schema Registry Yelp data pipeline 強制所有 message 走 Avro、自建 Schematizer 做 schema evolution 與 topic 自動分配。
• 2026-05-12 9.C14 Standard Chartered：受監管銀行的 Aurora 4000 TPS 容量提升 Standard Chartered 銀行遷移到 Aurora 後吞吐量提升 10 倍至 4000 TPS、跨 7 個受監管市場
• 2026-05-07 0.14 企業選型案例圖譜 蒐集不同類型與不同規模企業的技術選型案例，作為後端選型判讀的跨情境補充。
• 2026-05-01 6.14 Dependency Reliability Budget 把內外依賴的可靠性納入 SLO 計算與設計約束
• 2026-05-01 8.14 Multi-incident Coordination 把同時多事故的優先序、資源分配與 incident command system pool 協調變成可執行流程
• 2026-06-22 0.15 跨模組 Checkout Episode：從資料寫入到觀測證據 以 checkout 為切片，走完 DB write → cache invalidation → event publish → observability evidence 四層串聯，標示各模組的交接欄位與失敗判讀
• 2026-06-22 4.15 Cost Attribution / Chargeback 把 observability 成本拆到團隊、產品、環境維度
• 2026-06-16 Firestore realtime listener 扇出與成本：snapshot 訂閱、re-read 計費與連線規模 Firestore 的 snapshot listener 提供即時同步、但訂閱的扇出、查詢結果變動的 re-read 計費與連線數會在規模下變成成本與效能瓶頸；本文展開 listener 的推送模型、訂閱範圍設計、五個 realtime 成本踩坑，以及即時需求超過 listener 該換推送架構的邊界
• 2026-06-16 Kafka Multi-tenant 治理：quota 限流、ACL 授權與 topic 生命週期 單一 Kafka 叢集承載多團隊時、quota 把頻寬與 request 容量切給每個租戶、ACL 把寫入與讀取權限綁到 principal、topic 命名規範劃出 ownership 邊界、生命週期治理回收死 topic 釋放 metadata 壓力。本文涵蓋 producer_byte_rate / consumer_byte_rate / request_percentage 三類 quota 與 user / client-id / 組合三種套用層級、StandardAuthorizer 的 principal × resource × operation × host 授權模型、prefixed ACL 的 tenant 隔離、TopicGC 式的死 topic 回收、以及四個 production 故障演練（單租戶暴衝吃滿頻寬、ACL 過鬆過緊、topic 數量爆炸壓垮 controller、unused topic 未回收）
• 2026-06-16 Redis 持久化與 fork latency：AOF、RDB 與那一次卡住整個 cluster 的 fork Redis 的 RDB save 與 AOF rewrite 都靠一次 fork()，而 fork 在大記憶體實例上會凍結主執行緒數百毫秒、複製分頁讓記憶體逼近翻倍。本文展開 AOF / RDB 的機制與 fsync 取捨、copy-on-write 的記憶體放大、5 個把持久化寫成延遲尖峰與資料遺失的 production 踩坑，以及 cache 場景到底要不要持久化的邊界
• 2026-05-19 MySQL Orchestrator Failover：HA 工具自己怎麼 HA？raft cluster + GTID-based promotion 的兩段 paradox Orchestrator 是 MySQL HA 自動 failover 的 de facto standard、但讀者第一個問題往往是「HA 工具自己會壞嗎」。本文走 Orchestrator 的雙層架構（管 MySQL 的 raft cluster + 被 raft 管的 orchestrator instance）→ topology discovery → failure detection → failover decision tree → promote action → 5 production 踩雷（split-brain 跟 fencing / pre-failover hook 失敗 / anti-flapping window / GTID errant transaction / VIP 跟 ProxySQL 整合斷層）→ 跟 ProxySQL / Patroni / RDS 對比
• 2026-05-19 PostgreSQL Index Selection：B-tree / GIN / GiST / BRIN / Hash 對應 workload 的決策樹 PG 有 6 種 index method（B-tree / Hash / GIN / GiST / SP-GiST / BRIN）跟 partial / expression / covering 三種變體、不是「都用 B-tree 就好」。每種 index 有自己的 query pattern、儲存代價、write amplification 跟 maintenance 成本。本文走 6 種 index 的適用 workload 對照、決策樹、partial / expression / covering / multi-column 變體、5 production 踩雷（過度 index / partial 條件不對 / B-tree 對 JSON 無效 / BRIN 對非 correlated 資料無效 / multi-column 順序錯）、跟 query-optimization 的 EXPLAIN 互補
• 2026-05-18 3.C15 Airbnb：Spark Streaming Kafka reader rebalance Airbnb logging pipeline 解 partition-task 1:1 造成的 data skew、catch-up 4 小時 lag 要再花 4 小時的反效率。
• 2026-05-12 9.C15 拓元 Tixcraft：售票搶購的瞬間爆量架構 拓元用 DynamoDB 當寫入緩衝 + 傳統伺服器當慢速消費者、承受 100K+ 同時選位 + 30 秒從 6 台擴到 800 台
• 2026-05-01 6.15 Environment Parity 與漂移控制 把 staging / preprod / prod 之間的差異視為一級風險，按漂移來源分類偵測與治理
• 2026-05-01 8.15 Vendor / 第三方依賴事故處理 依賴方掛掉、自己無 control 時的決策模型
• 2026-06-16 Redis Sentinel 與 failover 時序：從 master 死掉到 client 重連的每一段 Redis Sentinel 的 failover 不是一個瞬間動作，是 down 偵測 → quorum 確認 → 選主 → 提升 → 配置廣播 → client 重連的一條時序鏈，每一段都有自己的延遲與失敗模式。本文展開 Sentinel 的判定模型與這條時序、5 個讓 failover 卡住或丟資料的 production 踩坑，以及 Sentinel 撐不住該往 Cluster 或 managed 走的邊界
• 2026-05-19 MySQL InnoDB Tuning：為什麼一個 100 GB DB 在 64 GB RAM server 上 query 慢 5 倍 InnoDB 是 MySQL 預設 storage engine、預設值給 256 MB buffer pool（早期 default）。本文從一個常見痛點開場（DB > RAM 但 server 仍 swap）、走 4 個 critical knob（buffer pool / redo log / flush method / IO capacity）、各自如何影響讀寫吞吐、配置 step-by-step、5 production 踩雷（buffer pool warm-up / log file 大小 / 設 sync_binlog=0 換速度 / IO scheduler / undo log 膨脹）、跟 SSD / NVMe / EBS 的 IO 假設
• 2026-05-18 3.C16 Robinhood：Faust Python stream processing Robinhood 每天 billions of events、Python 團隊不想用 JVM 生態、把 Kafka Streams 移植到 Python。
• 2026-05-12 9.C16 SeatGeek：DynamoDB + Lambda 打造的虛擬等候室 SeatGeek 用 DynamoDB 4 張表 + Lambda Bouncer 實作 flash-sale 限流排隊機制、取代第三方 waiting room 服務
• 2026-05-02 4.16 Observability Readiness Review 在服務上線、重大變更與演練前檢查 log / metric / trace / alert 是否可支援事故判讀
• 2026-05-01 6.16 Test Data Management 把 fixture / seed / production-like data 作為跨模組共用 artifact，治理資料層次、遮罩策略與可重現性
• 2026-05-01 8.16 Runbook Lifecycle 管理 把 runbook 從一次性文件變成有版本、有演練、會過期的 artifact
• 2026-06-16 Redis 連線與 pipeline：RTT 稅、連線池與一次往返打包多命令 Redis 單命令通常微秒級執行，但 application 端量到的延遲是毫秒級——差距全在網路往返（RTT）。pipelining 的本質不是『批次發命令』，是把 N 次 RTT 壓成 1 次。本文展開 RTT 會計、連線池配置、pipeline 與 MULTI 的差異、5 個把連線與往返寫成延遲與正確性問題的 production 踩坑，以及連線模型撞牆的邊界
• 2026-05-19 MySQL Binary Log + CDC：Maxwell / Debezium 是 binlog 第二消費者 MySQL CDC 跟 PostgreSQL logical decoding 是不同 abstraction — PG logical decoding 是 *logical event*（INSERT / UPDATE / DELETE）、MySQL CDC 是 *讀 binlog row-level event*。Maxwell / Debezium 是 binlog 第二消費者（跟 replica 共享 binlog stream），並非 PostgreSQL 式 logical replication 系統。本文走 binlog 三種 format（STATEMENT / ROW / MIXED）、ROW format 的 raw event 結構、Maxwell vs Debezium 對比、配置 step-by-step、5 production 踩雷（binlog retention / DDL event / row image / Kafka producer 跟 binlog reader 速度差 / schema change 跟 CDC consumer 同步）
• 2026-05-18 3.C17 Walmart：Messaging Proxy Service 解 rebalance storm Walmart 每天 trillions of message、25K+ consumer 在 K8s、partition-consumer 1:1 模型撞到擴張極限。
• 2026-05-12 9.C17 BookMyShow：印度年售 2 億張票的資料架構現代化 BookMyShow 從 15 年自建 analytics 遷移到 AWS modern data architecture、4 個月完成、分析成本下降 80%
• 2026-05-02 4.17 Telemetry Data Quality 把 missing signal、schema drift、sampling bias 與 timestamp skew 變成資料品質問題
• 2026-05-01 6.17 Feature Flag Governance 把 feature flag 從上線開關升級為有角色分類、lifecycle 管理與 debt 治理的 runtime artifact
• 2026-05-01 8.17 Security Incident vs Operational Incident 分流 把資安事故跟可用性事故的 IR 流程分支點明確化
• 2026-05-19 MySQL Vitess Sharding：VTGate / VTTablet / VReplication / VSchema 四件套協作 Vitess 不只是 MySQL sharding proxy、是 4 個 component 協作的完整 sharding 系統 — VTGate（query routing layer）、VTTablet（per-MySQL agent）、VReplication（跨 shard 資料移動）、VSchema（sharding metadata）。本文走 4 件套各自責任、keyspace / shard / tablet 架構、shard key 設計（Vindex）、配置 step-by-step、5 production 踩雷（cross-shard transaction / VStream lag / Vindex 不均勻 / resharding 切流 / VReplication 卡住）、跟自管 sharding 跟 PlanetScale 的對比
• 2026-05-19 PostgreSQL Citus Distributed：用 extension 把 PG 變成 sharded cluster Citus 是 PG extension、把單機 PG 變成 *coordinator + worker* sharded cluster、保留 PG SQL + 加 distributed table + reference table + columnar storage。本文走 Citus 架構（coordinator / worker / distribution column）、3 種 table type（distributed / reference / local）、配置 step-by-step、5 production 踩雷（distribution column 選錯 / cross-shard transaction / reference table 過大 / colocate 不對齊 / worker failover）、跟 MySQL Vitess sharding sibling 對比
• 2026-05-18 3.C18 Wix：Greyhound TLLSR 解 consumer 卡住 Wix 2000+ microservice 66B msg/day、自建 Greyhound 抽象、TLLSR 框架解 single-partition lag / poison pill / handler 卡住。
• 2026-05-12 9.C18 Zoom：COVID 期間從 1000 萬到 3 億 DAU 的 30 倍突發 Zoom 在 2020 年 COVID 爆發時、日活從 1000 萬衝到 3 億、用 DynamoDB 撐住會議後端
• 2026-05-02 4.18 Observability Operating Model 定義 platform / service team / on-call 對訊號、dashboard、alert 與成本的 ownership
• 2026-05-02 8.18 Incident Intake & Evidence Triage 把告警、客訴、支援回報與第三方狀態轉成同一個 intake / evidence 判讀流程
• 2026-05-01 6.18 Reliability Metrics Governance DORA / SPACE 指標的選用、量測陷阱、anti-gaming 與團隊階段適配
• 2026-05-27 0.19 雲端服務對照地圖（AWS / GCP / Azure） 把後端能力分類對照到 AWS / GCP / Azure 的具體服務名稱、保留跨雲遷移與選型差異的判讀重點
• 2026-05-19 MySQL 8.0 Modern SQL：CTE / window function / JSON_TABLE 不是「終於跟上 PG」、是進入 SQL 工程深度的入場券 MySQL 8.0 在 SQL 特性上 *終於補齊* CTE、window function、lateral derived table、JSON_TABLE、hash join 等現代 SQL 特性。本文走 5 個關鍵特性、各自實際 production 場景、跟 PostgreSQL 對應特性的行為差異（特別是 JSON_TABLE vs PG JSONB / jsonb_path_query）、配置 / migration 注意事項、5 production 踩雷（CTE 不 materialize / window function 大量 sort spill / JSON_TABLE 跟 generated column 取捨 / hash join 預設沒開 / recursive CTE 深度上限）
• 2026-05-19 PostgreSQL SQL Features：PG 早就有的、MySQL 8.0 才補的、PG 仍領先的 PG 在 SQL features 上長期領先 MySQL — CTE / window function / lateral / partial index / FTS / JSONB / GIN index / materialized view 在 PG 早 5-15 年。MySQL 8.0（2018）補多數但 *index / storage / extension* 層仍是 PG 結構優勢。本文整理 PG 早期就有的特性、MySQL 8.0 補的差異、PG 仍領先的、跟 MySQL modern-sql-features sibling 反向視角
• 2026-05-18 3.C19 Wix：Multi-cluster Kafka zero-downtime 遷移 Wix metadata 從 5K topic 漲到 20K topic / 200K partition、controller startup 跟 broker stability 受壓垮、分多 cluster 解決。
• 2026-05-12 9.C19 Capcom：Resident Evil / Monster Hunter 在 DynamoDB + EKS 上的遊戲後端 Capcom 把 Resident Evil、Street Fighter、Monster Hunter 遊戲後端跑在 DynamoDB + EKS、單一秒位數延遲、營運成本降 30%
• 2026-05-02 4.19 Debuggability by Design 把可診斷性前移到 API、async workflow、dependency call 與錯誤模型設計
• 2026-05-02 6.19 Reliability Readiness Review 把上線前、重大變更前與高風險操作前的可靠性準備度變成可檢查門檻
• 2026-05-02 8.19 Incident Decision Log 把事中假設、決策、證據、回退條件與責任人留下可復盤紀錄
• 2026-05-19 MySQL Group Replication / InnoDB Cluster：single-primary vs multi-primary mode 對 transaction certification 的影響 MySQL Group Replication 提供 synchronous multi-primary replication、用 Paxos-like Group Communication Engine（GCE）達成 quorum-based commit。但「multi-primary」不是「single-primary 多開幾個 write 入口」、是 *transaction conflict detection + certification* 整個機制不同。本文走 GR 機制（GCE + certification + applier）、single-primary vs multi-primary mode、InnoDB Cluster 跟 MySQL Shell / Router 整合、5 production 踩雷（cert lag / write conflict / large transaction / network partition / member 加入 catch-up）、何時用 GR 何時用傳統 replication
• 2026-05-19 PostgreSQL BDR / Multi-Master：active-active 寫入的 3 種路徑跟 conflict 治理 PG 預設是 single-primary、active-active 多寫入入口需要 *BDR (EDB)* / *pgEdge* / *Bucardo* 等 extension。本文走 3 種 multi-master 方案對比、conflict detection + resolution model、async vs sync 取捨、配置 step-by-step（pgEdge 為主）、5 production 踩雷（last-write-wins data loss / sequence collision / DDL replication / conflict log 治理 / failover 後 timeline 分歧）、跟 MySQL Group Replication sibling 對比
• 2026-05-18 3.C20 Spotify：Event Delivery 從 Kafka 遷出（反例） Spotify Kafka 0.7 MirrorMaker best-effort 會掉資料但回報成功、broker restart 後 producer 無法恢復、決定遷到 GCP Pub/Sub。
• 2026-05-12 9.C20 Zomato：從 TiDB 遷移到 DynamoDB、吞吐 4 倍、延遲降 90%、成本減 50% Zomato 帳單系統從 TiDB 遷移到 DynamoDB、吞吐 2K→8K RPM、延遲降 90%、成本減 50%
• 2026-05-02 4.20 Observability Evidence Package 把 log、metric、trace、audit 與資料品質限制包成可交接證據
• 2026-05-02 6.20 Experiment Safety Boundary 定義 chaos、load test、DR drill 的 [blast radius](/backend/knowledge-cards/blast-radius/)、停止條件與權限約束
• 2026-05-02 8.20 Customer Impact Assessment 把受影響用戶、功能、區域、金額、SLO 與補償判斷串成影響評估模型
• 2026-06-16 Memcached → Redis：不搬資料、搬存取層的能力升級遷移 Memcached → Redis 跟一般 migration 最大的不同：cache 是可重建的，所以這個遷移不搬資料、讓新 cache 重新 warm 就好，真正的工作在存取層（client、協定）跟可選的能力升級（data types）。本文跑 6 維 diff audit、用兩階段（drop-in pure KV → 採用 data types）結構、5 個把『outgrew pure KV』寫成事故的踩坑
• 2026-06-11 0.21 交付形態選型：從全託管到自建的光譜與邊界 在進入資料庫、快取與部署選型之前、先判斷服務該用託管平台（Wix / Shopify / Google Sites）、辦公生態自動化（Apps Script）、BaaS（Firebase）、半託管 CMS（WordPress）還是自建、並為日後遷往自建保留可遷出路徑
• 2026-05-19 MySQL Query Optimization：從 EXPLAIN 看到實際執行、5 條 query 從 5 秒變 50ms 的 anatomy MySQL query 慢的根因不在「SQL 寫法」、在「optimizer 選錯 plan」。本文從 5 個常見 production case 開場（5 秒 → 50ms / 30 秒 → 200ms / 8 秒 → 30ms 等）、走 EXPLAIN / EXPLAIN ANALYZE / optimizer trace 三層分析工具、index hint vs optimizer hint 取捨、cardinality estimation 失效時的修法、5 production 踩雷（statistics 過時 / forced index 用錯 / hash join 沒觸發 / range scan 退化 ALL / derived table materialization）
• 2026-05-19 PostgreSQL Query Optimization：EXPLAIN ANALYZE / pg_hint_plan / auto_explain 三層工具跟 4 個 case PG query 慢的根因常是 *planner 選錯 plan 或 statistics 過時*。本文從 4 個 production case 開場（seq scan vs index / hash vs nested loop / 多 column 統計缺 / parallel query 沒觸發）、走 EXPLAIN / EXPLAIN ANALYZE / auto_explain 三層工具、pg_hint_plan extension 跟 planner GUC 取捨、5 production 踩雷（ANALYZE 過時 / multi-column statistics / cost-base setting 不對齊硬體 / random_page_cost SSD 沒調 / parallel query 配置）、跟 MySQL query-optimization sibling 對比
• 2026-05-18 3.C21 Goldman Sachs：MSK 遷移 with MirrorMaker 2 Goldman Sachs Global Investment Research 從 on-prem Kafka 遷到 MSK、用 MM2 同步 topic/ACL/offset、atomic cutover 7 小時完成。
• 2026-05-12 9.C21 ASOS：Cosmos DB 在 Black Friday 撐 1.67 億請求 ASOS 在 2016 Black Friday 用 Azure Cosmos DB 撐 24 小時 1.67 億請求、3500 req/sec、48ms 平均延遲
• 2026-05-07 4.21 Rule-level CPU Signal Governance 把規則與策略執行成本變成可觀測訊號，避免控制面小變更在資料面形成 CPU 熱點。
• 2026-05-07 Datadog：2023 多區觀測中斷事件 監控平台自身退化時，如何避免客戶誤判系統健康狀態。
• 2026-05-07 Honeycomb：以 Burn Rate 驅動的可靠性操作 把 SLO burn rate 直接連到值班決策與改善優先序，降低高噪音告警造成的判讀失真。
• 2026-05-07 Netflix：Steady State、Chaos 與 FIT 的驗證路徑 把故障注入從工具操作升級成可驗證流程：先定義穩態，再設計注入與回復條件。
• 2026-05-02 6.21 Reliability Debt Backlog 把反覆事故、演練缺口與手動修復累積成可排序、可關閉的 reliability debt
• 2026-05-02 8.21 Incident Workflow Automation Boundary 定義哪些事故流程適合自動化，哪些決策需要保留人工確認
• 2026-06-16 自管 Redis / Valkey → AWS ElastiCache：engine 不變、變的是誰運維 自管 Redis/Valkey 遷到 ElastiCache 的特殊之處：engine 沒變（Redis 還是 Redis）、data model 沒變、API 沒變——變的只有運維責任歸屬。本文跑 6 維 diff audit 對映 Type C operational hybrid、展開 VPC/安全/cutover 的實際工作、以及『把 failover/patching 交出去、同時交出哪些控制權』的責任邊界，5 個 production 踩坑
• 2026-06-14 0.22 能力級買 vs 建：feature-as-a-service 與 BaaS bundle 選型 在交付形態決定整個系統要不要自建之後、逐能力判斷該外包還是自建：辨識 managed 基礎設施、feature SaaS 與 BaaS bundle 三種外包深度、no-code 到 dev-tool 的服務光譜、買 vs 建判準與權重浮動、整合接縫與遷出代價
• 2026-05-19 MySQL Partitioning：partition lifecycle 五段、跟 Vitess sharding 不同的「同 instance 內水平切割」 MySQL native partitioning 是 *同一個 MySQL instance 內的水平切割*、不是 Vitess sharding（跨 instance）。本文走 partition lifecycle 五段（design → create → query → maintenance → drop）、4 種 partition type（RANGE / LIST / HASH / KEY + COLUMNS / sub-partitioning）的 trade-off、partition pruning 怎麼運作、5 production 踩雷（PK 必須含 partition key / global index 沒原生 / partition exchange 細節 / orphan partition / cross-partition query 慢）、跟 PG declarative-partitioning 對比
• 2026-05-18 3.C22 Trivago：KEDA scale-to-zero by Kafka lag Trivago 50+ Kafka sink、CPU/mem autoscaling 無效（I/O bottleneck）、KEDA 以 consumer lag 為訊號達到 scale-to-zero。
• 2026-05-12 9.C22 Wayfair：用 GCP 提供 Way Day / Black Friday 的 burst capacity Wayfair 22M+ 商品 + 16,000+ 供應商、用 GCP 補充 on-prem data center 在峰值事件的 burst capacity
• 2026-05-08 4.22 Checkout API Evidence Package 實作示範 用 checkout 路徑示範 evidence package 如何交接給 release gate 與 incident decision。
• 2026-05-07 Netflix：Business-Hours Chaos 與 Guardrails Chaos Monkey 為何刻意在 business hours 執行：把即時應變能力納入驗證，並用 guardrails 限制實驗風險。
• 2026-05-02 6.22 Steady State Definition 在 chaos 與 failover 前先定義系統應維持的穩定狀態與可接受退化
• 2026-05-02 8.22 Incident Evidence Write-back 把事故證據、決策與復盤結論回寫到 observability、reliability 與 runbook
• 2026-06-22 4.23 觀測查詢設計 把觀測資料的讀取路徑當系統設計問題處理：三種查詢模式、storage tiering、pre-aggregation 與資源治理
• 2026-05-19 MySQL PITR + Backup Strategy：備份不是「拷貝資料」、是 N 點任意 restore 的能力 MySQL backup 不只是 mysqldump、是 *full backup + binlog 連續流* 組合才能達成 PITR（point-in-time recovery）。本文走「PITR 是能力、不是動作」、3 種 backup tool 對比（mysqldump / Percona XtraBackup / MyDumper）、binlog-based recovery 流程、配置 step-by-step、5 production 踩雷（GTID 處理不一致 / binlog gap / backup 沒 verify / RPO 不到 1 分鐘的代價 / encryption key 沒備份）、跟 PG pitr-wal-archiving sibling 對比
• 2026-05-18 3.C23 Bloomberg：多租戶 vhost + 自助平台化 Bloomberg 從幾個團隊推到上百個團隊、靠自助 vhost 註冊跟專用叢集分離應用與 broker。
• 2026-05-12 9.C23 Netflix：把關聯式 DB 統一到 Aurora、效能 +75%、成本 -28% Netflix 把多套關聯式 DB 統一到 Aurora、效能提升 75%、成本下降 28%、串流數十億小時
• 2026-05-08 8.23 Control Plane Decision Log and Write-back 實作示範 以 rule/config rollout 事故示範 decision log 與 write-back 如何形成可回放閉環。
• 2026-05-08 Netflix：FIT 證據交接與 Release Gate 回寫 用 Failure Injection Testing 產出的證據直接驅動 release gate：把實驗結果轉成可放行、可凍結、可回退的決策欄位。
• 2026-05-02 6.23 Verification Evidence Handoff 把 SLO、load、chaos、DR 與 readiness 結果包成 release / incident 可用證據
• 2026-06-22 4.24 Client-to-Server 端到端觀測串接 用一個結帳場景走完 browser click → trace context → server span → 統一 waterfall 的完整實作鏈路
• 2026-06-22 Retry Policy 說明重試策略如何區分暫時性錯誤、永久錯誤與副作用風險
• 2026-05-19 MySQL Lock Contention：在 staging 重現的 deadlock、production 跑 6 個月才出現 MySQL InnoDB 的 lock 是 row-level、但 *為什麼某些 row 莫名其妙也被 lock* 是 gap lock / next-key lock 設計造成的隱性行為。本文從一個 production case 開場（staging 重現 deadlock / production 6 個月後突然爆）、走 5 種 InnoDB lock 類型（record / gap / next-key / insert intention / auto-inc）、isolation level 對 lock 行為的決定性影響、deadlock detection / SHOW ENGINE INNODB STATUS 解讀、5 production 踩雷（gap lock 阻塞 INSERT / auto-inc lock contention / FK lock cascading / large transaction lock holding / READ COMMITTED 跟 binlog ROW 互動）
• 2026-05-19 PostgreSQL MVCC + Lock Model：為什麼 PG 比 MySQL 少 deadlock、但 vacuum 是別的代價 PG 用 *MVCC-heavy + 少 explicit lock* 的並行控制、跟 MySQL InnoDB 的 *lock-based*（record / gap / next-key）相反。本文走 MVCC 機制（tuple version + xmin/xmax + visibility）、PG 4 種 lock（row-level / table-level / advisory / predicate）、預測 SERIALIZABLE 行為、5 production 踩雷（idle transaction 卡 vacuum / SELECT FOR UPDATE 跨 transaction / advisory lock 沒釋放 / bloat 不是 vacuum 問題 / predicate lock 在 SSI 下 rollback）、跟 MySQL lock-contention sibling 對比
• 2026-05-18 3.C24 SoundCloud：AMQP fan-out 音訊處理 pipeline SoundCloud 每秒 20-30K persistent message、不同處理類型分開隊列、各自獨立 scale。
• 2026-05-12 9.C24 Genesys：用 DynamoDB 在 15 region 跑出 99.999% 可用性 Genesys 客服平台用 DynamoDB 為預設資料層、跨 15 主 region + 5 衛星 region、達成 12 個月 99.999% 可用性
• 2026-05-07 6.24 規則推送安全閘門 把規則、策略與控制面配置推送從部署步驟升級為可靠性 gate，避免小變更在秒級擴散成全網事故。
• 2026-05-19 MySQL 5.7 → 8.0 Major Version Upgrade：character set / authentication / atomic DDL 三條 paradigm 同時換軌 MySQL 5.7 → 8.0 三條 default 同時改：charset utf8 → utf8mb4、auth plugin native_password → caching_sha2_password、DDL non-atomic → atomic。本文走 Type E paradigm shift 結構、6 維 audit、4-phase upgrade、5 production 踩雷、何時不要升級。
• 2026-05-19 PostgreSQL JSONB Deep Dive：Binary Storage + GIN Index 為什麼是結構性優勢 PG JSONB（9.4+）是 *binary 儲存的 JSON*、可直接 GIN index、是 PG 在 JSON workload 的結構性優勢、跟 MongoDB / MySQL 8.0 JSON_TABLE 比仍領先。本文走 JSON vs JSONB 差異、GIN index 機制（jsonb_ops vs jsonb_path_ops）、operator + path query、partial JSONB indexing、5 production 踩雷（大 JSONB 跟 TOAST / nested update / index 選錯 op class / jsonb_path_query 跟 jsonb_path_exists 行為差 / partial index 條件搞錯）、何時用 JSONB vs 拆 column
• 2026-05-18 3.C25 Indeed：Delay queue + DLQ 三層 escalation Indeed 每天 35M+ 職缺、設計 Requeue → Delay queue → DLQ 三層 escalation 避開 head-of-line blocking。
• 2026-05-12 9.C25 Tubi：從 ScyllaDB 遷到 ElastiCache、ML feature store 達 sub-10ms p99 Tubi 把 ML 推薦的 feature store 從 ScyllaDB 遷到 ElastiCache for Redis、99 百分位延遲降到 10ms 以下
• 2026-05-08 6.25 Provider Dependency Release Gate 實作示範 以 payment provider 變更示範 release gate 如何結合 evidence、stop condition 與 rollback window。
• 2026-05-19 MySQL → Aurora MySQL：storage layer 轉手到 AWS、replication / HA / backup 全部 outsource 自管 MySQL → Aurora MySQL 是 Type C operational hybrid migration — wire protocol 一致、ops 責任轉到 AWS。本文走 6 維 audit（Operational High）、Aurora storage architecture 衝擊、4-phase migration、5 production 踩雷、何時維持原路線。
• 2026-05-19 PostgreSQL Extension Ecosystem：把 PG 變成 vector DB / time-series / sharded 的 plugin 生態 PG 的 extension 機制不只是 plugin、是 *結構性產品線擴張* — pgvector 讓 PG 變 vector DB、TimescaleDB 變 time-series、Citus 變 sharded、PostGIS 變 GIS。本文走 PG extension lifecycle、6 個 production-critical extension（pg_stat_statements / pg_partman / pg_repack / pgvector / TimescaleDB / PostGIS）、5 production 踩雷（extension version 跟 PG version 對齊 / managed PG 限制 / upgrade order / shared_preload_libraries 衝突 / extension 跟 logical replication 互動）、cloud vendor 對 extension 的限制
• 2026-05-18 3.C26 GoCardless：Hutch + 單一 topic exchange service mesh GoCardless 單一 RabbitMQ cluster 作所有 service 通訊中樞、routing key 用 service.subject.action 格式、JSON 多語言可讀。
• 2026-05-12 9.C26 PayPay：行動支付每日 3 億訊息的 DynamoDB 後端 日本最大行動支付 PayPay 每日 3 億訊息、用 DynamoDB 處理通知與訊息功能、支撐次秒級反應
• 2026-05-19 MySQL → PlanetScale：managed Vitess + branch-based schema workflow 的 hybrid shift 自管 MySQL → PlanetScale 加上 Vitess sharding 跟 branch-based schema workflow。本文走 6 維 audit（Paradigm + Operational + Schema 多軸）、4-phase migration、5 production 踩雷、何時不要遷。
• 2026-05-19 PostgreSQL Full-Text Search：tsvector / tsquery / GIN index 跟 pg_trgm fuzzy 三層搜尋 PG 內建 full-text search 用 *tsvector / tsquery / GIN index* 三件組、適合中小規模搜尋（< 100M 文件）；pg_trgm 提供 fuzzy match。本文走 FTS 機制（tsvector 是 lexeme + position 的 vector）、3 種 query（match / ranking / weighted）、multi-language support、跟 pg_trgm fuzzy match 互補、5 production 踩雷（dictionary 選錯 / GIN 跟 GiST 取捨 / ranking 評分權重 / multi-language column 處理 / 何時不該用 PG FTS 改 Elasticsearch）
• 2026-05-18 3.C27 Zalando：RabbitMQ on AWS 自動化 master selection Zalando 用 sidekick 服務查 AWS API 動態識別 cluster、指定最老 instance 當 master、跨版本升級用 federation 過渡。
• 2026-05-12 9.C27 Disney+：DynamoDB 撐每日數十億動作的觀看歷史 Disney+ 用 DynamoDB 撐每日數十億動作的觀看歷史、watchlist、播放進度等串流 metadata
• 2026-05-08 7.27 Credential Rotation with Scoped Evidence 實作示範 以 webhook/API credential 輪替示範 scope map、證據欄位與回退窗口如何一起設計。
• 2026-05-19 PostgreSQL Replication Slot Management：Physical / Logical / Failover Slot 治理 PG replication slot 是 *primary 端的 standby 進度紀錄*、防 WAL premature deletion。但 orphan slot 會吃 disk、failover 後 logical slot 不會自動跟新 primary、是 PG 操作的 hidden complexity。本文走 physical / logical slot 差異、slot lifecycle、failover slot synchronization（PG 17+ 新特性）、orphan slot 治理、5 production 踩雷（orphan slot disk 爆 / logical slot lag / failover 後 slot 丟 / wal_keep_size 跟 slot 衝突 / connection 同時打 slot 數量限制）
• 2026-05-19 自管 Vitess → PlanetScale：Vitess component ops outsource、加 schema workflow shift 自管 Vitess → PlanetScale 是 Type C operational hybrid — Vitess component（VTGate / VTTablet / VReplication / VSchema）ops outsource + branch workflow。本文走 6 維 audit、4-phase migration、5 production 踩雷、何時不要遷。
• 2026-05-18 3.C28 WeWork：Consistent hash exchange 保證帳戶順序 WeWork 固定數量 queue + account ID hash 路由、每 queue 一個 worker + exclusive consumer 保 partition-level ordering。
• 2026-05-12 9.C28 FanDuel：體育直播 + 投注的雙重峰值 FanDuel 3.5M MAU、Super Bowl 期間擴容 5-10 倍、用 AWS Local Zones + Wavelength + Outposts 處理 20+ 州的雙重峰值
• 2026-05-19 TimescaleDB Deep Dive：Hypertable / Continuous Aggregate / Compression 把 PG 變 Time-Series DB TimescaleDB 是 PG extension（不是 fork）、用 *hypertable* 自動 partition by time、加 *continuous aggregate* 做 incremental materialized view、加 *compression* 對舊 chunk 壓 90%+、把 PG 變成 InfluxDB / Prometheus 級 time-series DB。本文走 hypertable 機制、continuous aggregate 跟普通 MV 差異、compression policy、retention policy、5 production 踩雷（chunk size 不對 / CAGG refresh 落後 / compression 後 update 限制 / hypertable 不能加 FK / TimescaleDB 跟 PG 主版本對齊）、跟 PG 原生 partitioning 對比
• 2026-05-18 3.C29 WeWork：Bunny + Puma 多執行緒 channel pool WeWork 從 Unicorn 切到 Puma 後遇 ConnectionClosedError、根因是 AMQP channel 跨執行緒共用、改用 connection_pool 管理。
• 2026-05-12 9.C29 NTT DOCOMO Lemino：3 個月達 500 萬 MAU 的串流後端 Lemino 用 DynamoDB + AWS Media Services 撐 30 channels live + 5M MAU、工程工時下降 90%
• 2026-05-27 Aurora Storage Architecture：quorum-based 分散式 log 與韌性即性能設計 Aurora storage / compute 分離、6-way 跨 AZ replication、4-of-6 write / 3-of-6 read quorum、韌性投資自動 amortize 成 read 性能、DraftKings 6ms 寫 / <1ms 讀 production reference
• 2026-05-27 CockroachDB HLC + Raft Consensus：軟體時鐘 + per-range 共識的 latency 與容量結構 CockroachDB 用 Hybrid Logical Clock + per-range Raft 做跨節點線性化、不靠 TrueTime 原子鐘。本文走 HLC / Raft / range / leaseholder 四層機制、寫入 latency 構造、failure mode（clock skew panic / Raft majority lost / hot range）、引用 DoorDash Aurora 撞牆訊號（1.636 M QPS 屬 Aurora 痛點而非 CockroachDB 容量證明）+ Netflix 380+ artery of small DBs 容量規劃顆粒
• 2026-05-27 Cosmos DB MongoDB API vs SQL API：遷移路徑、dogfood signal、multi-model、跨雲 hedging 從『MongoDB API 跟 SQL API 哪個快』推進到 vendor selection 的四層問題：三型遷移路徑、dogfood signal 怎麼讀、multi-model 差異化、跨雲 hedging — 從 Microsoft 365 dogfood 案例切入
• 2026-05-27 DynamoDB Single-Table Design：從適用度前置判讀到 access pattern 反推 PK/SK DynamoDB single-table 設計不是「資料表越少越好」，而是 access pattern 反推 PK/SK 跟 GSI；本文先做 DynamoDB 適用度 4 軸前置判讀（PK 天然均勻 / control plane vs data plane / consistency / access pattern 穩定），再展開設計流程、failure modes 與 durable queue 正向用例
• 2026-05-27 MongoDB Schema Design Pattern：contract layer 在哪 vs embedded / reference MongoDB document schema 真正的 production 議題不是 embedded vs reference 二選一、是 schema contract 該放 DB 層 validator 還是 app 層 abstraction；含 Toyota polymorphic governance、Forbes abstraction layer、time-series collection 邊界
• 2026-05-27 Spanner TrueTime API 深度：GPS + 原子鐘、commit wait、為什麼 line-rate scaling 才是設計目的 TrueTime 是手段、line-rate scaling 才是 Spanner 的設計目的。本文先扣商業邏輯：傳統 OLTP coordinator 為什麼是 bottleneck、Spanner 怎麼用 TrueTime + Paxos 換成拓樸感知多 leader；再展開 TrueTime ε / commit wait 數學、ε 暴衝失敗模式、cross-region voting 對 latency 的影響、跟 9.C10 Google internal dogfood 揭露的線性擴展模式對照
• 2026-05-19 pgvector Deep Dive：HNSW / IVFFlat 取捨跟跟專業 Vector DB 對比 pgvector 是 PG extension、加 *vector* type 跟兩種 ANN index（IVFFlat / HNSW）、把 PG 變成可用 vector DB。本文走 vector type + distance operator、IVFFlat vs HNSW 取捨（build time / recall / memory）、quantization 跟 dimension reduction、5 production 踩雷（dimension 超 2000 限制 / HNSW build 太慢 / IVFFlat 不重建 recall 漂移 / hybrid search 設計 / memory budget）、跟 Pinecone / Weaviate / Milvus 對比的決策框架
• 2026-05-18 3.C30 Runtastic：Mirrored queue 網路負載瓶頸 Runtastic 2020 lockdown 流量暴增、performance test 揭露 mirroring 邏輯把網路元件壓垮、調整 mirroring 配置消除瓶頸。
• 2026-05-12 9.C30 Microsoft 365：從 MongoDB 遷移到 Cosmos DB 的分析平台 Microsoft 365 把使用分析平台從 MongoDB 遷移到 Cosmos DB、planet-scale 全球分散式分析
• 2026-06-02 Aurora Serverless v2 適用判斷：ACU 自動擴縮、混合 cluster 與何時不該用 Aurora Serverless v2 不是「比較便宜的 Aurora」；本文展開 ACU 計費粒度、秒級自動擴縮機制、min/max ACU 設定、serverless 與 provisioned 同 cluster 混用，以及穩定高負載下 serverless 反而更貴的成本 crossover 邊界
• 2026-05-27 DynamoDB Partition Key 反模式與 Write Sharding：composite key 修復跟 mode × partition 交叉判讀 DynamoDB partition 上限 1000 WCU 是 hot partition 的根因；composite key（event_id + shard suffix）跟 calculated shard（hash % N）兩種修法、mode × partition 在 provisioned / on-demand 不同表現，以及 9.C15 Tixcraft 6750x 擴展的工程細節
• 2026-05-27 MongoDB Shard Key Selection：hashed vs ranged、單 cluster 切 shard vs 多 cluster 切 blast radius MongoDB sharded cluster shard key 選型（hashed / ranged / compound）、單 cluster 分 shard vs 多 cluster 分 blast radius 對照、跟 DynamoDB / Cosmos DB partition key 可逆性的跨 vendor 紀律
• 2026-05-27 Spanner Consistency Models 對照：external consistency vs serializability vs linearizability external consistency、serializability、linearizability 是三個常被混用的概念。本文先精確定義三者差異、再用 line-rate scaling 對照表（PG SSI / CockroachDB / Spanner / Aurora DSQL）回答為什麼 Spanner 不只是『更強的 serializable』、最後用 9.C10 揭露的 cross-region quorum 100-200ms 物理硬限解釋『強一致 + 全球部署』的真實 cost
• 2026-05-19 PostGIS Deep Dive：Geometry / Geography 型別、GiST 空間索引跟 ST_* 函式生態 PostGIS 是 PG extension、加 *geometry* / *geography* 型別、GiST 空間索引跟 1000+ ST_* 函式、把 PG 變成功能完整 GIS DB（跟 Oracle Spatial / SQL Server geography 並列）。本文走 geometry vs geography 取捨、SRID 跟投影系統、GiST 空間索引機制、5 production 踩雷（geometry 用錯 SRID / geography 不能用所有 ST_ 函式 / GiST index 不對 ST_DWithin 生效 / cluster on geom 後 BRIN 失效 / EWKB vs WKB 跨工具相容）、GIS workload 的 PG vs 專業 GIS DB 對比
• 2026-05-18 3.C31 Mozilla Pulse：命名前綴 + ACL 取代 vhost 多租戶 Mozilla Pulse 不用 vhost、改用權限 + 命名前綴 (exchange/{user}/*) 做隔離、CloudAMQP 託管、PulseGuardian 管使用者。
• 2026-05-12 9.C31 Mercado Libre：LatAm 電商在 GCP 上用 Vertex AI 搜尋 1.5 億商品 Mercado Libre 1 億客戶 + 1.5 億商品、用 GCP Vertex AI Search + BigQuery 提供近即時搜尋與分析
• 2026-05-07 Amazon：Shuffle Sharding 與 Cell 邊界的失效局部化 用 cell 與 shuffle sharding 將多租戶故障限制在局部，讓恢復策略可分批執行。
• 2026-05-07 Discord：Gateway 容量事件與恢復節奏 長連線平台在容量邊界被擊穿時，如何控制擴散並分批恢復。
• 2026-05-07 LinkedIn：Capacity Headroom 與 On-call 分層 把容量預測與值班分層綁在一起，降低高峰時段的升級混亂與恢復延遲。
• 2026-06-23 Amazon：Static Stability 與 Constant Work Pattern 控制面失效時資料面如何維持服務：用快取、預計算與固定工作量避免恢復放大。
• 2026-06-23 Honeycomb：Production Excellence 與 Test in Production 用 high-cardinality observability 把 production 變成安全的驗證環境：feature flag、progressive rollout 與即時回饋的配合。
• 2026-06-23 LinkedIn：Automated Load Testing 與 Capacity Forecasting 持續壓測驅動容量預測：用自動化回饋取代一次性壓測的容量規劃。
• 2026-06-22 Log Schema 說明結構化 log 欄位如何支援搜尋、關聯與事故排查
• 2026-06-02 Aurora 多 cluster 按業務切分：微服務私有 store、blast radius 隔離與 fleet 治理 把所有服務塞進一個大 Aurora cluster 會讓單一服務的查詢拖垮全部；本文展開按業務 / 微服務切 cluster 的判斷維度、blast radius 隔離、共用 vs 分離的成本與運維 surface 權衡，以及多 cluster fleet 的治理一致性，含 Netflix Aurora consolidation 對照
• 2026-05-27 DynamoDB GSI 與 LSI 設計：access pattern 補位、projection、consistency 跟 DAX 補位 GSI / LSI 是 single-table 沒覆蓋的 access pattern 補位、不是萬靈丹；本文涵蓋 projection 三型選擇、sparse index、GSI 自己會 hot partition、DAX 讀峰值補位的觸發條件（含 Capcom 是 derive vs Lemino 是 case fact 的分層）
• 2026-05-27 MongoDB Replica Set Read Preference：DB 層 causal session vs cache 層 freshness token MongoDB read preference 五擇一 + read concern + causal consistency session 機制；DB 層機制解 cluster 內 read-your-own-write、cache 層 freshness token 解跨層 read-after-write、大規模 OLTP 必須兩層合用
• 2026-05-27 Spanner Schema Migration Without Downtime + Interleaved Tables Spanner DDL 是 long-running operation、用 TrueTime 給每次 schema change 分配 version timestamp、所有 read / write 對應自己 transaction timestamp 看到對應 schema。Interleaved table 是 storage-level parent-child 物理交錯、不是 logical FK。本文走 schema change lifecycle、interleaved layout 機制、backfill capacity 影響、5 production 踩雷、跟 PostgreSQL online schema change 對照
• 2026-05-18 3.C32 LoyaltyLion：監控數千 RabbitMQ queue LoyaltyLion 跑數千 queue、用 rabbitmqctl + statsd 推 Datadog、揭露大規模 queue 拓樸下原生 plugin API 不夠用。
• 2026-05-18 PostgreSQL autovacuum tuning：為什麼你的 autovacuum 永遠追不上 bloat MVCC 怎麼產生 dead tuple、autovacuum cost-based throttle 為什麼預設保守、per-table tuning 怎麼設、5 個 production 踩雷（cost_limit 太低 / 長 transaction blocks vacuum / anti-wraparound 在 peak / partition vacuum 滿 worker / index bloat 沒處理）、跟 partitioning + monitoring 整合
• 2026-05-13 9.C32 Clearent：Azure SQL Hyperscale 撐每年 5 億筆支付交易 Clearent 在 Azure SQL Hyperscale 上處理每年 5 億筆支付交易、autoscale + 微服務架構
• 2026-06-22 Metrics 說明指標如何描述服務趨勢、容量與健康狀態
• 2026-06-02 Aurora RDS Proxy 與連線管理：connection multiplexing、pinning 陷阱與 failover 加速 RDS Proxy 不是「連上去就自動省連線」；本文展開 connection multiplexing 機制、哪些 session 操作會觸發 pinning 讓 multiplexing 失效、failover 期間 proxy 如何保持 client 連線縮短中斷，以及 RDS Proxy 與自管 pgbouncer 的責任切分
• 2026-05-27 DynamoDB On-Demand vs Provisioned：6 軸決策、auto-scaling 邊界與 cost crossover capacity mode 選擇不是單軸 peak/avg ratio；本文展開 6 軸決策（peak/avg / 讀寫比 trend / surge 暫時 vs 永久 baseline / predictable-peak vs flash-sale / DBA 工時釋放 / vendor vs 自管 cost crossover），含 Zomato 50% 成本下降、Zoom 30x permanent surge、Amazon Ads sustained workload 等 case 分軸 anchor
• 2026-05-27 Migration Playbook：Cloud SQL for PostgreSQL → Cloud Spanner Cloud SQL → Spanner 是 paradigm shift 級遷移、不是 drop-in。本 playbook 走 6 規格面 Driver / Diff / Phase / Evidence / Cutover / Cleanup：Driver 段明示 sizing barrier（100 pu 起跳）跟 < 50ms write latency 兩條 no-go；Diff 段加 sizing / cost 第 7 規格面；Phase 0 含 sizing audit；Evidence 段補 cost crossover 報告；對照 9.C10 Google internal dogfood 邊界跟 Standard Chartered 受監管 banking case
• 2026-05-27 MongoDB Connection Management and Cache Layer：driver × 部署模型 × cache × predictive scaling MongoDB 大規模 OLTP 撞牆不是單一 driver 議題、是 driver × 部署模型 × cache × scaling trigger 三層協作；含 Coinbase mongobetween / freshness token / ML 預測擴容三件套 + 適用範圍紀律
• 2026-05-18 3.C33 Wargaming：World of Tanks 戰後 dossier 解耦 Wargaming WoT server 全 Linux、戰後 dossier 寫 RabbitMQ、portal 顯示統計而不增 game server load。
• 2026-05-18 PostgreSQL declarative partitioning：partition 不是切表、是讓 planner pruning Declarative partitioning 的真實價值是 query planner pruning + maintenance scope 縮小、不是「把大表切小」；RANGE / LIST / HASH 取捨、partition key 選法、5 個 production 踩雷（key 選錯不 prune / unique 不 enforce 跨 partition / ATTACH 鎖太久 / partition 數爆 / DETACH 不 reclaim 空間）、跟 autovacuum + index 設計整合
• 2026-05-13 9.C33 Maersk + Bosch：傳統產業在 Azure AKS 上的微服務治理 全球海運 Maersk 跟 Bosch 智慧建築把 AKS 當微服務治理基礎、釋放工程資源做業務功能
• 2026-06-22 SLI / SLO 說明服務品質指標與服務品質目標如何連接產品承諾
• 2026-06-02 Aurora PG/MySQL vs Aurora DSQL 取捨：何時 single-region managed 夠用、何時跨到 distributed Aurora DSQL 不是 Aurora 的升級版而是不同 paradigm；本文聚焦『standard Aurora（single-region managed SQL）什麼時候夠用、什麼時候需要跨到 active-active distributed』的升級門檻決策，切分『怎麼遷』（migrate-to-aurora-dsql）與『DSQL vs Spanner vs CockroachDB 三方選型』（decision-tree）兩個既有 SSoT
• 2026-06-02 Spanner Change Streams (CDC)：捕捉資料變更、watch partition、下游整合與 DynamoDB Streams 對照 Change Streams 是 Spanner 把 commit 後的 row mutation 變成可消費事件流的 CDC 機制、用 data change record 攜帶 commit timestamp 把外部一致性延伸到下游。本文走 change stream 物件模型、watch partition 的 child partition 切分、Dataflow / Pub/Sub 下游整合、retention 與 staleness 失敗模式、跟 DynamoDB Streams 的 partition / ordering / retention 對照
• 2026-05-27 DynamoDB Global Tables：multi-region active-active、LWW conflict 與 cross-device sync 正向用例 Global Tables 不只是 conflict 痛點、也是 cross-device sync / global read / DR failover 的正向工程方案；本文展開 B2B SaaS vs B2C 業務 driver、LWW conflict resolution、reconciliation pipeline，含 Genesys 99.999% 跨 15 region 跟 Disney+ 跨裝置同步的對照
• 2026-05-27 MongoDB Aggregation Pipeline Optimization：stage 順序、index 配合與 memory 邊界 MongoDB aggregation pipeline stage 順序、index 配合、100MB memory 邊界、cross-shard `$lookup` 限制；report dashboard 跑爆 primary 的 anti-pattern 治理路徑
• 2026-05-18 3.C34 Netlify：NATS 當全球 metrics/logs 統一資料平面 Netlify 70K+ 網站、10 億 PV/月、跨多雲、NATS 當 all-purpose data plane fan-out bus、超 RabbitMQ 評估。
• 2026-05-18 PostgreSQL Logical Replication + Debezium CDC：replication slot × failure × recovery 對照 PostgreSQL logical replication slot 跟 Debezium CDC 的失效模式對照表：slot lag 撐爆 primary disk / schema change 斷流 / 初始 COPY 鎖表 / zombie slot 不釋放 / replay storm 後 offset reset；publication / subscription / pgoutput 配置、跟 Kafka outbox pattern 整合
• 2026-05-13 9.C34 GCP：130,000-node GKE cluster 的工程極限 Google 用單一 GKE control plane 跑 13 萬個 node、AI workload + 1000 Pods/sec 創建吞吐
• 2026-06-22 Trace Context 說明跨服務 request 如何用 trace context 串起路徑與耗時
• 2026-06-02 DynamoDB Transaction 與 Conditional Write：跨 item 原子性、optimistic locking 與 idempotency DynamoDB 的寫原子性不是免費 ACID；本文展開 TransactWriteItems 跨 item 原子性、ConditionExpression 條件寫、version-based optimistic locking、ClientRequestToken idempotency，以及 transaction 2x 成本邊界與何時用單 item conditional write 取代 transaction
• 2026-06-02 Spanner PostgreSQL dialect：PG-compatible interface vs GoogleSQL、相容子集邊界、何時選 PG dialect Spanner PostgreSQL dialect 是建在 Spanner 分散式引擎之上的 PG-compatible 介面、提供 PostgreSQL 語法、型別與 wire protocol、但不是完整 PostgreSQL。本文先定義 PG dialect 跟 GoogleSQL dialect 的責任差異、再劃相容子集邊界（哪些 PG 功能不在、哪些 Spanner-only 概念仍要懂）、最後給選 dialect 的決策判準與 dialect 不可變更的失敗代價
• 2026-05-27 MongoDB Change Streams + Kafka 整合：resume token、scope 選擇與 connector 治理 MongoDB change streams 機制（resume token、oplog 容量、cluster-wide vs collection-level scope）跟 Kafka Connector 整合；at-least-once 語義 + idempotency 治理 + resume token 過期防護
• 2026-05-18 3.C35 Form3：NATS JetStream 多雲低延遲支付 Form3 服務 Tier-1 銀行、500ms SLA、SNS/SQS 吃 300ms 預算、改 NATS+JetStream 跨雲 6x 延遲改善。
• 2026-05-18 PostgreSQL PITR + WAL archiving：從 base backup 到 point-in-time recovery 的完整鏈 Base backup + WAL archive 構成 PITR 的雙軌資料、archive_command + restore_command 配置、用 pgBackRest / WAL-G 替代手寫腳本、5 個 production 踩雷（archive 靜默失敗 / archive lag / 錯誤 target time / base backup 過期未清 / timeline 分歧 recovery 模糊）、跟 Patroni + monitoring 整合
• 2026-05-13 9.C35 Snap：GCP + KeyDB 在 multi-cloud 架構下的低延遲快取 Snap 用 GCP 上的 KeyDB cluster 減少跨 cloud cache 延遲、用 TPU 訓練廣告推薦模型
• 2026-06-02 DynamoDB DAX 快取策略：cluster 架構、item/query cache、write-through 與 invalidation 邊界 DAX 不是「加上去就變快」的開關；本文展開 DAX cluster 架構、item cache vs query cache 兩種快取、write-through 一致性語意、query cache 只靠 TTL 失效的陷阱，以及 strongly consistent read 繞過 cache 的邊界，含 Lemino 讀峰值補位 case fact 與 gsi-lsi-design 的 SSoT 切分
• 2026-06-02 Spanner Graph (2024)：property graph 能力、跟 relational 表共存、適用場景與邊界 Spanner Graph 是建在 Spanner relational 引擎上的 property graph 能力、用 GQL 查詢 node 與 edge、底層仍是 relational table、graph 跟 SQL 共用同一份資料與 transaction。本文走 graph 物件模型（node / edge table 映射）、跟 relational 共存的設計、GQL 查詢、graph schema 不可逆設計的失敗代價、何時用 graph、何時用純 relational 或專用 graph DB
• 2026-05-26 9.C36 Coinbase：MongoDB 撐 Ruby 單體 + 1.5M reads/sec identity 服務 Coinbase 以 MongoDB 為主資料層、自建 mongobetween connection proxy、users 服務在加密貨幣 surge 時撐 1.5M reads/sec
• 2026-05-18 3.C36 Intelecy：工業 IoT 即時感測 + 多租戶 Intelecy 工廠 gateway 接數萬感測器、< 2 秒往返延遲做即時 ML、從 BoltDB 本地快取演進到 JetStream 持久化。
• 2026-06-02 DynamoDB Streams 與 Lambda 事件驅動：CDC、shard 順序保證、消費模式與失敗處理 DynamoDB Streams 不是免費的可靠事件流；本文展開 stream record 的四種 view type、shard 對應 partition 的順序保證邊界、Lambda event source mapping vs Kinesis 消費模式、at-least-once 下游冪等需求，以及 batch 失敗時的 bisect / DLQ 處理
• 2026-06-02 Spanner ↔ BigQuery federation：OLTP/OLAP 分工、federated query、Data Boost、何時把分析 workload 分出去 Spanner 是 OLTP、BigQuery 是 OLAP、federation 讓 BigQuery 直接查 Spanner 的活資料、Data Boost 讓分析查詢用獨立運算資源不搶 OLTP CPU。本文先定義 OLTP/OLAP 的責任分工、再走 external dataset federated query、Data Boost 的 workload 隔離機制、federation vs change-stream-to-BigQuery 兩條整合路線的取捨、以及何時該把分析 workload 完全分出去
• 2026-05-26 9.C37 Forbes：自管 MongoDB → Atlas on GCP、build 時間 25 → 9 分鐘 Forbes 把自管 MongoDB 遷到 Atlas on Google Cloud、6 個月完成、build 25 → 9 分鐘、120M 不重複訪客單月承接
• 2026-05-18 3.C37 MachineMetrics：邊緣到雲端工廠資料管線 MachineMetrics 跨數百工廠、數千機台、1000Hz 採樣、Kinesis 無法跑在 edge、改 NATS Leaf Node + JetStream + KV + Object Store。
• 2026-06-02 DynamoDB TTL 資料生命週期：自動過期、48 小時刪除延遲、過期仍可讀與 storage 成本 DynamoDB TTL 不是即時刪除也不是查詢過濾器；本文展開 TTL attribute 的 epoch 語意、AWS 背景刪除的延遲特性、過期但未刪 item 仍會被讀到且仍計費的陷阱、TTL 刪除免 WCU 與觸發 stream 的整合，含 PayPay 訊息過期清理 case anchor
• 2026-05-26 9.C38 Toyota Connected：MongoDB Atlas 撐 900 萬車輛 telematics、月 180 億 transaction Toyota Connected 用 MongoDB Atlas 撐 Safety Connect 900 萬車、月 180 億 transaction、緊急訊號 3 秒內到 agent
• 2026-05-18 3.C38 Clarifai：NATS Streaming ML 平台非同步任務 Clarifai custom model 訓練、rolling deploy 掉訊息、改 NATS Streaming queue group、3 週遷移 1 服務、5 月 5 服務、每日 100k+ 訊息 100% uptime。
• 2026-06-02 從 RDS / MongoDB 遷移到 DynamoDB：access-pattern-first 重建模、混合架構與 cost crossover RDS / MongoDB → DynamoDB 不是搬 schema 而是換 paradigm；本文走 Type E paradigm shift 結構，展開為何字面遷移不成立、access pattern 重建模、哪些 workload 該遷哪些該留的混合架構、dual-write + shadow read 階段化，以及 Zomato cost crossover 的長期成本判讀
• 2026-05-26 9.C39 DoorDash：Aurora Postgres 寫入瓶頸 → CockroachDB 多主寫入 DoorDash 從 Aurora Postgres 遷到 CockroachDB、解 1.6 M QPS 單主寫入瓶頸、外送平台爆量壓力下重做 OLTP 拓樸
• 2026-05-18 3.C39 Choria：NATS 管 50 萬 server fleet Choria 替代 Puppet MCollective、NATS 單 binary 無 Zookeeper、4GB node 可達 50 萬 server、wildcard + queue group 做 scatter-gather RPC。
• 2026-05-27 Aurora Cross-AZ Failover：RTO 量測、endpoint routing 與 application reconnect 契約 Aurora cross-AZ failover lifecycle（detection / promotion / DNS update）、< 30 秒 RTO、application DNS cache 跟 connection pool 對齊、Standard Chartered 受監管場景為什麼用獨立 cluster 而非 Global Database failover
• 2026-05-27 CockroachDB Survival Goals：zone 級 vs region 級配置與業務 SLO 倒推流程 CockroachDB 用 SURVIVE ZONE FAILURE / SURVIVE REGION FAILURE 兩種 survival goal 宣告式控制 Raft replica 分佈、決定 RTO / RPO。本文走 Hard Rock Digital bet placement RPO=0 倒推流程、Netflix Gaming 48-node 跨 4 region 「為求 survival 而非 latency」的反直覺判讀、配置語法、寫入 latency 暴漲跟 cost 暴漲兩條失敗模式、合規邊界對比
• 2026-05-27 Cosmos DB RU/s 成本模型 + 容量規劃：RU 思維、payload、index、provisioned vs autoscale vs serverless 從 CPU+IOPS 思維轉到 RU 思維的學習曲線、依負載形狀選容量模式、payload + index policy 對 RU 的影響、autoscale reactive 限制 — 從 ASOS Black Friday + Minecraft Earth 1M RU/s 壓測切入
• 2026-05-26 9.C40 Netflix：380+ CockroachDB cluster 的 multi-active 拓樸艦隊 Netflix 把 Cassandra 不夠用的 transactional workload 移到 CockroachDB、380+ cluster / 60+ 跨 region、含 Open Connect、studio cloud drive、gaming control plane
• 2026-05-19 PostgreSQL major version upgrade (14 → 17)：為什麼這篇不套 5 type migration PostgreSQL major version upgrade 是 *5 type 漏類* 的實證 — source/target 同 vendor、5 維度都 Low 但 *upgrade-specific audit* 是核心；本文結構接近 deep article methodology 的 6-section + 額外 upgrade audit 段；涵蓋 pg_upgrade / logical replication / blue-green 三方法、extension 相容性、5 production 踩雷
• 2026-05-18 3.C40 Resgate：WebSocket-to-NATS realtime API gateway Resgate 把 NATS subject 暴露成 REST + WebSocket、subject 階層當 schema、event 延遲 < 1ms、純 Core NATS。
• 2026-05-26 9.C41 Hard Rock Digital：CockroachDB on AWS Outposts、Wire Act 合規 + 跨州單一邏輯 DB Hard Rock Digital 用 CockroachDB 跨 AWS Outposts + US-East-1、Wire Act 強制資料留州、單一邏輯 DB 解多州 sportsbook、100 node 32 vCPU 撐 Super Bowl
• 2026-05-19 PostgreSQL → Aurora Migration：protocol 相容、operational 重設計 Aurora 號稱 PostgreSQL-compatible 但 operational model 不同（storage decouple / cluster endpoint / instance class / 自家備份）；遷移流程是混合（protocol drop-in + operational phased）、5 個 production 踩雷（extension 不支援 / replication slot 不直通 / autovacuum 行為差 / IAM 認證強制 / cost model 換算）、跟 Patroni / read replica / DR 對位
• 2026-05-18 3.C41 i-flow：NATS 做 OT/IT 跨層整合 bus i-flow 每日 4 億筆 data operation、200+ OT/IT connector、客戶含 Bosch / Sto / Lenze、NATS 當邊緣到 central 整合 bus。
• 2026-05-07 Azure AD：2021 身分控制面中斷事件 身分服務失效時，如何評估跨產品影響與收斂優先序。
• 2026-05-07 Meta：Region Failover 與可靠性邊界 把跨區故障視為邊界治理問題，透過分區隔離與回復順序控制失效擴散。
• 2026-05-07 Stripe：Idempotency 與零停機遷移的交易安全設計 把 API 重試與資料遷移放在同一套安全模型，維持支付交易的一致結果。
• 2026-06-23 Meta：BGP 事故與控制面恢復順序 當回復工具依賴已故障的系統：2021-10 事故揭露控制面恢復順序與 out-of-band 存取的設計約束。
• 2026-06-23 Pinterest：Storage Migration 與 Data Infrastructure Reliability 大規模儲存遷移的可靠性設計：用 dual-write、shadow read 與 staged cutover 讓 PB 級資料基礎設施變更可漸進、可驗證、可回退。
• 2026-06-23 Spotify：Backstage Service Catalog 與 Reliability Metadata 用 service catalog 治理分散團隊的可靠性資訊：ownership、SLO 狀態、依賴圖與 runbook 的單一入口。
• 2026-06-23 Stripe：Canary Deploy 與 Progressive Rollout 治理 金流場景如何用交易指標驅動放行節奏：延遲確認、duplicate 偵測與自動回退。
• 2026-05-19 PostgreSQL → Aurora DSQL Migration：PG wire-compatible Distributed SQL 的 Paradigm Shift Aurora DSQL（2024-12 re:Invent preview / 2025-05 GA）是 AWS 推的 PG wire-compatible *active-active distributed SQL*、跟 self-managed PG / Aurora PG 不同 paradigm（OCC + snapshot isolation + multi-region strong consistency）。Migration 結構是 *protocol drop-in + paradigm shift*：app SQL 不太改、但 transaction retry / extension 缺位 / 多 region 一致性需重設計。本文走 DSQL vs Aurora PG vs self-managed PG 三軸對比、為什麼遷的三條 driver（global write / operational zero-touch / region resiliency）、Type E phased plan、5 production 踩雷（transaction retry 沒處理 / extension 缺位 / sequence throughput 限制 / Aurora PG 直升 DSQL 不可行 / region failover semantic）、跟 PG → Aurora 跟 PG → CockroachDB 對比
• 2026-05-18 3.C42 Bitso：Reliable Redis Streams 抽象 + 自建 DLQ Bitso 加密交易所、千 msg/sec/stream + 亞毫秒延遲、自建 Reliable Streams 封裝 PEL + retry + DLQ、idempotent processing。
• 2026-05-19 PostgreSQL → CockroachDB：三維皆 High 的多重歸類 migration PostgreSQL → CockroachDB 是 Schema / Operational / Paradigm 三維皆 High 的 multi-axis migration、實證 [#127](/report/content-structure-by-max-diff-dimension/) 的「多重歸類跟 tie-breaking」規則；主結構走 Type E paradigm shift、Schema 差 + Operational redesign 抽出獨立段；涵蓋 transaction model 重設計、SQL dialect gap、5 個 production 踩雷
• 2026-05-18 3.C43 Arcjet：Redis Streams 取代 Kafka 省 6 位數 $ Arcjet security 平台、Kafka managed 6 位數 $/yr、用 Redis Streams 約 $1k/yr、自寫 Janitor 監控 retention。
• 2026-05-19 PostgreSQL Partition Redesign：當 monthly partition 越跑越慢 PostgreSQL partition redesign 是 Type F「topology re-layout」第 2 個 dogfood — 從 monthly partition 改 daily / 從 range 改 list / 從單軸改 sub-partition；6 維 audit 皆 Low + topology 軸 High；涵蓋 partition 不平衡偵測、ATTACH/DETACH 線上重劃、5 個 production 踩雷、跟 partition_pruning + autovacuum 整合
• 2026-05-18 3.C44 Harness：CD 微服務 async state transfer Harness CD 平台用 Redis Streams 解 brittle HTTP、揭露監控缺口 / MAXLEN truncation / head-of-line blocking 三類問題。
• 2026-05-19 PostgreSQL Multi-Region GDPR Rollout：政策驅動的 migration 屬本 methodology 嗎 PostgreSQL 單 region → multi-region 同時滿足 GDPR EU residency 是 *政策驅動* 兼 *topology 變動* 兼 *operational redesign* 的多軸 migration；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 提出的 residency axis 候選 — residency 是 driver 還是獨立 audit 軸；涵蓋 logical replication 配 GDPR / 5 個 production 踩雷 / cross-region cost
• 2026-05-18 3.C45 Klaxit：Rust + Redis Streams 處理 Heroku Logplex Klaxit carpool 用 Redis Streams 處理 Heroku Logplex 匯流、自動偵測修復平台 perf 問題、6 個月 production Rust。
• 2026-05-18 3.C46 Learning.com：Redis 事件源退場（反例） Learning.com 把 microservice event store 放 Redis、1 年累積 GB/週、AOF+EBS 變 latency 痛點、退到 PostgreSQL。
• 2026-05-18 3.C47 PHP 微服務：Redis Streams + S3 hybrid storage PHP 雙微服務通訊、Kafka 在 PHP 生態工具薄弱、用 Redis Streams + payload compression + S3 hybrid 處理大訊息。
• 2026-05-18 3.C48 Airbnb Dynein：SQS 分散式延遲任務排程 Airbnb 用 SQS at-least-once + DLQ 取代 Resque 單 Redis 限制、每 scheduler 1000 QPS、SQS wrap DynamoDB 處理 > 15 分鐘 delay。
• 2026-05-18 3.C49 Airbnb Inspekt：Visibility timeout 當 retry budget Airbnb Inspekt 隱私掃描器、scanner pull message、visibility timeout 自然觸發重現、用重現次數當 retry budget。
• 2026-05-27 Aurora Read Replica Scaling：15 replica 上限、lag profile、headroom 預留與 fleet 治理 Aurora 15 replica 上限、共享 storage 為什麼能養大量 replica、事件型容量分級表、DraftKings headroom 預留判讀、FanDuel 雙 SLO 並行、fleet 治理 3 條 driver（business sharding / microservice / 合規）
• 2026-05-27 CockroachDB Transaction Retry Pattern：serializable default 與 application contract 重塑 CockroachDB default SERIALIZABLE、application 必須包 retry loop 處理 40001 serialization_failure。本文走 PG → CockroachDB application contract 重塑視角、SAVEPOINT cockroach_restart 語法、5 種失敗模式（retry storm / 非冪等 / cross-statement state / hot row / long-running transaction）。**整篇是跨 case 合成 frame**：DoorDash case 沒揭露 retry pattern、只揭露 PG wire protocol 相容 + SQL 行為仍要 audit、本章 retry contract 重塑屬通用工程議題從 Cockroach Labs 官方 docs 合成
• 2026-05-27 Cosmos DB Multi-Region Write：active-active、LWW、custom merge、Strong + multi-region 互斥的 AP 取捨 Multi-region active-active write 的 conflict resolution（LWW / custom merge / conflict feed）、Strong 跟 multi-region write 為什麼互斥、廣告 SLA vs 實測可用性鏈路拆解 — 從 Minecraft Earth + Toyota Connected 切入
• 2026-05-18 3.C50 Capital One：Visibility timeout 設計與 Lambda event source Capital One tech blog 講 SQS + Lambda：visibility timeout 應略高於最大處理時間、Lambda 初 5 個 long polling、可擴 60/min。
• 2026-05-18 3.C51 Atlassian JiRT：Kinesis + SQS subscription Atlassian StreamHub Kinesis 底層、每 consumer 自己一個 SQS queue、JiRT 把輪詢 1 min 改成秒級 event-driven。
• 2026-05-07 Heroku：Routing 控制事件與多租戶影響 PaaS 路由層異常時，如何限制租戶擴散並維持可用通訊。
• 2026-05-07 Microsoft：變更治理與可靠性門檻 透過分層變更管理與發布閘門，降低大型 SaaS 平台的系統性回歸風險。
• 2026-05-07 Shopify：BFCM 容量治理與 Game Day 驗證節奏 把季節性流量峰值轉成年度可靠性流程，透過容量模型、演練與隔離策略提前吸收風險。
• 2026-06-23 Microsoft：Safe Deployment Practices 與 Resilience Patterns 大型 SaaS 用 ring-based deployment 控制變更擴散，用標準化 resilience patterns 讓依賴失效時的降級行為可預測。
• 2026-06-23 Shopify：Pod Architecture 與 Resiliency Matrix 多租戶隔離與系統化失敗模式盤點：pod 邊界控制擴散、resiliency matrix 驅動演練。
• 2026-05-18 3.C52 Nielsen：Spark on EKS 雙 SQS 工作流 Nielsen 每日 25TB / 30B event、work queue + completion queue 雙 SQS、queue depth autoscale EKS pod。
• 2026-05-18 3.C53 FINRA：S3 → SQS notification 大檔上傳 FINRA 金融監管、broker 上傳大檔、S3 → SQS notification → LFS、KMS + bucket policy + queue policy 三層稽核。
• 2026-05-18 3.C54 Twitch EventSub：SNS+SQS fan-out 給第三方 Twitch Event Bus ~1660 events/sec 進 SNS、EventSub 用 SQS 接收 + Dispatcher fan-out 給訂閱者。
• 2026-05-18 3.C55 SmugMug：SQS 驅動可重放搜尋管線 SmugMug 用 SQS 兩種模式：DynamoDB scan-segment 平行 backfill + production query 鏡像 replay 到 replica。
• 2026-05-18 3.C56 PostNL EBE：完整 DLQ + retention + redrive 設計 PostNL 物流每天 1000 萬訊息、每 producer/consumer 隔離 stack、24h 內 100 次 retry、final DLQ 可 consumer redrive。
• 2026-05-18 3.C57 Lob：自家 fork @lob/sqs-consumer 修 FIFO bug Lob 原用 bbc/sqs-consumer 鎖 SDK v2、fork 出 @lob/sqs-consumer 支援 SDK v3 + TypeScript + 修 FIFO bug。
• 2026-05-18 3.C58 Twilio：SQS 緩衝高流量 webhook Twilio 教用 SQS 緩衝 SMS / status callback webhook、分 queue（SMS vs callback）、long polling 減 cost、FIFO 300 TPS 上限要分片。
• 2026-05-18 3.C59 Rapid7：SQS 100 億 message/day 規模 Rapid7 公開引述：SQS 撐 10s of billions of messages per day、是架構關鍵元件、scale 量級的具體參考。
• 2026-05-27 Aurora Global Database：跨 region async replication、< 1 秒 lag 與合規 anti-recommendation Aurora Global Database 跨 region storage-level async replication、< 1 秒 typical lag、planned vs unplanned failover RTO 數量級對比、Standard Chartered 合規禁止跨境複製為什麼讓 Global Database 變反指標
• 2026-05-27 CockroachDB Locality-Aware Schema：跨州合規 + 邏輯一個 cluster 的 region placement 策略 Hard Rock Digital 跨 8 州 sportsbook、用 AWS Outposts + region placement 把運算釘在州內、邏輯上仍是一個 CockroachDB cluster。本文走 REGIONAL BY ROW / REGIONAL BY TABLE / GLOBAL 三種 locality、Hard Rock 拓樸創新對比 Standard Chartered Aurora 7 cluster fleet、AWS Outposts 是合規工具不是 latency 工具的反直覺判讀
• 2026-05-27 Cosmos DB Partition Key Design：synthetic / composite / hierarchical + 不可逆性硬約束 Cosmos DB logical partition 10000 RU/s 上限、partition key 不可改、三種設計模式（synthetic / composite / hierarchical）、跟 DynamoDB / MongoDB 可逆性對比、latency budget 拆解 — 從 Minecraft Earth + ASOS 切入
• 2026-05-18 3.C60 Spotify：Event Delivery 從 Kafka 遷到 Pub/Sub Spotify 全球 event delivery 從 Kafka 遷到 Pub/Sub、~2500 VM、Q1 2019 8M events/s、350TB/day raw、自建 dedup。
• 2026-05-18 3.C61 Spotify：Autoscaling Pub/Sub consumer 反效果 Spotify 下游失敗時 consumer 不 ack 仍耗 CPU、autoscaling 越拉越高、解法是 exponential backoff 抑制 CPU。
• 2026-05-07 Pinterest：快取可靠性與容量驚奇治理 針對快取層失效與流量突增，建立容量緩衝、退化路徑與重建節奏。
• 2026-05-07 Reddit：2023 Kubernetes 升級事故 平台升級變更如何觸發服務退化，以及如何設計可回退的升級策略。
• 2026-05-18 3.C62 Spotify：Pub/Sub → GCS reliable export Spotify 用 Oldest Unacknowledged Message metric 判斷 hourly bucket 何時可安全關閉、ack 綁定下游 commit。
• 2026-05-18 3.C63 Mercari Actionable History：ack deadline 是 batch-level Merpay 支付流水帳用 Pub/Sub、ack deadline 是整批 batch 而非單訊息、acked 訊息會跟同批 expired 一起 redeliver。
• 2026-05-18 3.C64 Mercari Item Feed：DLT 防 poison message 阻塞 Mercari 商品 feed 同步、ack 整批 / nack 重送、重試多次仍失敗送 DLT、topic 同時當 load-leveling buffer。
• 2026-05-18 3.C65 Mercari LINE：Pull subscription 對齊外部 RPS Mercari LINE webhook 轉 Pub/Sub、worker pull subscription 精確控制 RPS、應 LINE API 限制。
• 2026-05-18 3.C66 Mercari B2C：自建 PubSub gRPC Pusher Mercari 全球商品同步、原生 HTTP push 在「長 job + 高吞吐 + 動態 RPS」場景受限、自建 gRPC 版 push。
• 2026-05-18 3.C67 Niantic Pokémon GO：Pub/Sub 當 telemetry ingest Pokémon GO frontend publish 玩家事件、~1M TPS、Pub/Sub elastic buffer、下游 BigQuery streaming。
• 2026-05-18 3.C68 Wix：Pub/Sub decouple + Dataflow + BQ archive Wix App Engine 收 clickstream 進 Pub/Sub、Dataflow 進 Datastore < 100ms、BigQuery 並行存 raw recovery。
• 2026-05-18 3.C69 Twitter Ad Engagement：把 stream 切成多 topic 做 partition Twitter 把 80K msg/s stream 切成 6 個 topic 做 partition、Avro schema、Beam/Dataflow → Bigtable/BQ。
• 2026-06-02 CockroachDB Multi-region Table 配置：三種 table locality 的選擇與 latency / 一致性取捨 CockroachDB 把 multi-region table 抽象成 REGIONAL BY TABLE / REGIONAL BY ROW / GLOBAL 三種 locality、每種對 read / write latency 跟一致性付不同成本。本文走三種 locality 的判讀軸、survival goal 怎麼跟 locality 一起決定副本拓樸（機制本身 cross-link survival-goals）、配置與驗證流程、選錯要重配的高代價回退、容量觀測訊號
• 2026-05-27 Cosmos DB 5 Consistency Levels：Session 預設、Bounded staleness、Strong 邊界跟跨 collection 分流策略 Cosmos DB 5 個 consistency level 的工程選擇邏輯、Session 為何是 production 預設、per-request override 跟跨 collection 分流的進階策略、Strong + multi-region 互斥的 cross-link — 從 Minecraft Earth + ASOS 切入
• 2026-05-27 從自管 PostgreSQL / MySQL 遷到 Aurora：operational redesign migration playbook PostgreSQL / MySQL → Aurora 的 Type C operational redesign hybrid playbook、6 規格面（Driver / Diff audit / Phase plan / Evidence / Cutover / Cleanup）、Standard Chartered 合規 lead time 模型、Netflix 非 all-purpose store 邊界
• 2026-06-02 Cosmos DB Change Feed (CDC)：persistent change log、Azure Functions trigger、latest-version vs all-versions-and-deletes 與跟 DynamoDB Streams 對照 Cosmos DB Change Feed 的工程展開：partition-scoped 持久變更 log、change feed processor 的 lease / continuation token、latest-version 與 all-versions-and-deletes 兩種模式的取捨、Azure Functions trigger 整合、跟 DynamoDB Streams 的語義差 — 從 ASOS catalog 寫入投影切入
• 2026-05-07 Microsoft 365：套件級身分驗證事故 企業套件在身份依賴失效時，如何同步處理跨產品影響與對外揭露。
• 2026-05-07 Spotify：平台工程與可靠性契約 用平台契約統一服務團隊的可靠性最低標準，降低跨團隊變更造成的隱性風險。
• 2026-06-22 Consumer Group 說明一組 consumer 如何共同分攤 stream 或 topic 的處理責任
• 2026-06-02 Cosmos DB Stored Procedure / Trigger（JavaScript）：partition-scoped 交易、server-side 邏輯邊界、何時用何時讓 application 層處理 Cosmos DB 用 JavaScript 寫的 stored procedure、pre/post trigger 與 UDF 的工程展開：single-partition transaction 語義、bounded execution 與 continuation 模式、何時值得用 server-side 邏輯、為何多數邏輯應留在 application 層 — 跟 Change Feed 的非同步路徑對照
• 2026-04-24 7.2 身分與授權邊界 以問題驅動方式整理身分、授權、會話與供應商身分鏈
• 2026-06-22 Partition 說明事件流如何切分成多個可並行處理的有序片段
• 2026-06-02 從 MongoDB / Cassandra 遷入 Cosmos DB：protocol-compat API drop-in vs native API paradigm shift、相容性邊界與 dual-write cutover MongoDB / Cassandra 遷入 Azure Cosmos DB 的 migration playbook：用 Cosmos 的 MongoDB API / Cassandra API 做 wire-protocol drop-in（Type B）vs 換 native SQL API 的 paradigm shift（Type E）兩條路徑的取捨、6 維 diff audit、相容性邊界、dual-write 與 cutover — 從 Microsoft 365 / Forbes 遷移對照切入
• 2026-04-24 7.3 入口治理與伺服器防護 以問題驅動方式整理對外入口、管理平面與伺服器邊界
• 2026-06-22 Offset 說明 consumer 在事件流中的讀取位置與重放基準
• 2026-06-02 Cosmos DB for PostgreSQL：基於 Citus 的分散式 PostgreSQL、跟核心 Cosmos DB 是不同產品、何時選它而非核心 Cosmos 或一般 PG Cosmos DB for PostgreSQL（2022、Citus-based distributed PG）的定位釐清：它是分散式 PostgreSQL、不是 NoSQL Cosmos DB；distribution column / coordinator-worker 架構、何時選它而非核心 Cosmos DB、何時夠用一般 Azure Database for PostgreSQL — 命名混淆的選型陷阱
• 2026-04-24 7.4 資料保護與遮罩治理 以問題驅動方式整理資料分級、遮罩、匯出與備份治理
• 2026-06-22 Retention 說明資料或事件保留多久，以及保留期限如何影響重放與成本
• 2026-06-02 Cosmos DB ↔ Azure Synapse Link：analytical store、HTAP federation、何時把分析 workload 從 OLTP 分出去 Cosmos DB Azure Synapse Link 的工程展開：column-oriented analytical store 自動同步、HTAP federation 讓分析 query 不打 OLTP transactional store、no-ETL 對 RU 的隔離、何時把分析 workload 從 Cosmos OLTP 分出去 vs 何時 federate 到專用 OLAP — 從 Microsoft 365 analytics 切入
• 2026-04-24 7.5 傳輸信任與憑證生命週期 以問題驅動方式整理傳輸信任鏈、會話完整性與憑證節奏
• 2026-04-24 7.6 秘密管理與機器憑證治理 以問題驅動方式整理 secret、token、key 與機器身份治理
• 2026-04-24 7.7 稽核追蹤與責任邊界 以問題驅動方式整理高風險操作追蹤、可回查與責任切分
• 2026-04-24 7.8 模組路由：問題到服務實作 整理問題節點如何路由到部署、可靠性與事故處理章節
• 2026-04-24 7.9 服務生命週期的資安風險節奏 定義設計、上線、變更、事故、復盤五段中的資安問題節點
• 2026-06-02 CockroachDB Cloud Serverless 適用判斷：按用量 vs dedicated 的取捨與 RU 計費結構 CockroachDB Cloud 的 serverless（按用量 RU 計費、自動 scale-to-zero）跟 dedicated（固定 cluster、自管容量）解不同的容量壓力。本文走 serverless 的 RU 計費結構與冷啟動 / scale 行為、何時 serverless 何時 dedicated 的判讀軸、用量暴衝的成本失控回退、跟 self-managed（Netflix Platform Team / Hard Rock 賽季擴縮）的責任對照
• 2026-04-24 7.10 Workload Identity 與聯邦信任邊界 定義非人類身份、跨平台信任與短時憑證治理問題
• 2026-04-24 7.11 資料駐留、刪除與證據鏈 定義跨區資料駐留、刪除請求與可驗證證據鏈問題
• 2026-04-24 7.12 供應鏈完整性與 Artifact 信任 定義 build provenance、artifact 信任與交付鏈風險問題
• 2026-04-24 7.13 偵測覆蓋率與訊號治理 定義偵測覆蓋、訊號品質與誤報成本的治理問題
• 2026-04-24 7.14 資安治理例外與 Tripwire 定義例外管理、風險接受與重新評估觸發器
• 2026-04-24 8.8 事故報告轉 workflow：從案例到日常流程 把事故報告拆成可執行流程，並與 red-team 案例庫建立雙向引用
• 2026-05-12 LLM Deployment 供應鏈完整性 把 LLM 模型權重、推論伺服器、第三方 plugin 三條 production 供應鏈納入既有 artifact trust 框架的判讀
• 2026-05-12 LLM 多租戶推論隔離 production LLM 服務的多租戶隔離：KV cache 不共享、log / model artifact 隔離、跨用戶 prompt 洩漏面
• 2026-05-12 LLM Agent Prompt Injection 後果治理 production LLM agent 場景的 prompt injection 後果：tool spec 設計、agent loop 限制、review checkpoint、跟 incident workflow 的接合
• 2026-05-12 LLM Log 與 PII 治理 production LLM 服務的 prompt log 累積、PII 偵測與過濾、保留期限與合規對齊
• 2026-05-12 LLM Service 偵測訊號覆蓋 production LLM 服務的 detection 訊號設計：tool call 異常模式、prompt injection 觸發徵兆、abuse 跟濫用模式、跟既有 detection-coverage 框架的接合
• 2026-06-22 Histogram 說明 histogram 如何用分桶統計延遲、大小與分布
• 2026-06-22 Percentile 說明 p95 與 p99 如何描述長尾延遲與使用者體驗
• 2026-05-27 CockroachDB vs Aurora DSQL vs Spanner：撞牆訊號分型 + 七問題決策樹 Distributed SQL 三選一決策樹。先用撞牆訊號分型識別 driver path（DoorDash 單主寫入撞牆 / Netflix Cassandra 缺口 / Hard Rock 合規驅動）、再走七問題（跨雲 / 雲商生態 / 風險預算 / PG 相容 / 管理負擔 / team size / vendor sizing barrier）。PostgreSQL 相容性 audit checklist 4 項、Spanner 100 pu sizing barrier、Hard Rock 「省 10-20 工程師」機會成本警示、Netflix Database Platform Team 規模
• 2026-05-18 PostgreSQL pgBouncer 配置 + 連線池治理 pgBouncer transaction pooling 配置、跟 application connection pool 的分層、production 故障演練（pool exhaustion / stale connection / DNS failover）跟容量規劃
• 2026-06-22 Error Budget 說明 SLO 允許的失敗額度如何影響發版與可靠性投入
• 2026-06-22 Burn Rate 說明 error budget 消耗速度如何支援告警與事故分級
• 2026-06-22 Correlation ID 說明跨事件或跨服務的關聯識別碼如何支援排障
• 2026-06-22 Trace ID 說明分散式追蹤中同一條呼叫路徑的識別碼
• 2026-06-22 Span 說明 trace 中一段工作如何記錄耗時、狀態與關聯
• 2026-06-22 Symptom-Based Alert 說明告警應優先偵測使用者可感知症狀
• 2026-06-22 Alert Fatigue 說明過多低品質告警如何降低 on-call 反應品質
• 2026-06-22 Queue 說明 queue 如何保存等待處理的工作並形成容量邊界
• 2026-06-22 Consumer 說明 consumer 如何取得等待處理的工作並產生業務結果
• 2026-06-22 Topic 說明 topic 如何把事件依主題分流給不同訂閱者
• 2026-06-22 Trace 說明 trace 如何重建跨服務請求的路徑、耗時與依賴關係
• 2026-06-22 Dashboard 說明 dashboard 如何把關鍵訊號組成可判讀的服務狀態畫面
• 2026-06-22 Fan-out 說明單一事件同時分發給多個下游的訊息拓撲
• 2026-05-11 Validation Query 說明遷移、回填與修復期間如何用查詢證明資料語意是否一致
• 2026-06-22 Alert 說明 alert 如何把需要處理的服務症狀轉成可行動通知
• 2026-05-11 Read Compatibility 說明資料或服務演進期間讀取路徑如何同時支援新舊語意
• 2026-06-22 Runbook 說明 runbook 如何把事故判斷與操作步驟標準化
• 2026-05-11 Fallback Read 說明讀取路徑切換失敗時如何暫時回到舊資料語意或舊讀取來源
• 2026-05-11 Cutover Window 說明正式切換發生的觀察窗口、停止條件與回退判讀範圍
• 2026-06-22 Event Log 說明事件歷史如何保存、重播與支援跨服務資料重建
• 2026-05-11 Mapping Table 說明遷移或轉換期間如何把舊語意明確對應到新語意
• 2026-06-22 Search Index 說明搜尋索引如何承擔全文檢索、排序與查詢體驗
• 2026-06-22 Read Model 說明為查詢場景建立的讀取模型，與正式狀態的責任分離
• 2026-06-22 Incident Timeline 說明事故時間線如何支援判斷、溝通與復盤
• 2026-05-11 Rollback Window 說明變更進入 production 後還能用哪種方式回退或改路線的時間與條件
• 2026-05-11 Fail-forward 說明無法回到舊狀態時如何用受控前進完成修復
• 2026-05-11 Stop Condition 說明變更、實驗或事故處理何時必須暫停、回退或改路線
• 2026-05-11 Gate Decision 說明 release gate 如何把證據轉成放行、暫停、回退或補證據的決策
• 2026-06-22 Projection 說明從事件流或資料變更推算出查詢用讀取視圖的轉換機制
• 2026-05-11 Rollback Condition 說明決策執行後出現哪些訊號時要撤回、回退或改路線
• 2026-06-22 On-Call 說明值班制度如何承接告警、事故分級與升級流程
• 2026-06-22 Ownership 說明 ownership 如何把問題、決策與交接責任固定到可執行角色
• 2026-06-22 Continuous Profiling 在 production 持續取得低 overhead profile 的觀察方法
• 2026-06-22 Action Item Closure 說明事故行動項如何被驗證完成，而不是只停留在待辦清單
• 2026-05-11 Time Range 說明證據、查詢與事故判讀如何用時間窗保留可回放上下文
• 2026-05-11 Query Link 說明證據包如何保存可重跑查詢入口，而不是只保留截圖或口頭結論
• 2026-05-11 Data Quality 說明證據欄位如何標示 completeness、freshness、sampling 與資料限制
• 2026-05-11 Confidence 說明證據包如何標示 confirmed、suspected 或 needs follow-up 的判讀信心
• 2026-05-11 Known Gap 說明證據包如何明確保存已知缺口，避免下游高估證據完整性
• 2026-06-22 Recording Rule 說明把 query-time 聚合計算推到寫入時的 pre-aggregation 機制
• 2026-06-22 Rollup / Downsampling 說明時間序列資料隨時間降低精度以控制儲存成本與查詢效能的機制
• 2026-06-22 Storage Tiering 說明按資料熱度分層儲存以平衡查詢速度、儲存成本與保留完整性的機制
• 2026-06-22 Materialized View 說明預先計算並儲存查詢結果以加速讀取的資料結構
• 2026-06-22 CQRS 說明讀寫不對稱時為何需要分離查詢與寫入責任、分離的判準與代價
• 2026-06-22 Event Sourcing 說明用 append-only 事件流取代 mutable state 作為正式紀錄的設計模式、需求判準與代價
• 2026-06-18 Outbound Tunnel 反向隧道把出站連線轉成可達入口、與傳統 port-forward 的責任倒轉
• 2026-04-24 7.R0 紅隊基礎：攻擊流程作為服務判讀語言 建立紅隊共同詞彙與流程視角，讓案例分析回到服務環節的決策判讀
• 2026-04-24 7.R1 攻擊面與信任邊界 從紅隊角度盤點系統暴露面，以及信任假設在哪裡開始失效
• 2026-04-24 7.R2 入口濫用與權限突破 說明合法功能如何被惡意組合成權限突破或流程濫用
• 2026-04-24 7.R3 資料暴露與外洩路徑 說明敏感資料會從哪些回應、紀錄或工具中流出
• 2026-04-24 7.R4 資源濫用與可用性破壞 說明攻擊者如何把合法操作放大成容量壓力或服務退化
• 2026-04-24 7.R5 設定錯誤與隱藏入口 說明 debug、預設值與環境差異如何意外暴露能力
• 2026-04-24 7.R6 事故故事重構：服務環節問題與注意事項 以統一模板整理案例：服務環節問題地圖、案例對照表與跨模組交接邊界
• 2026-04-24 7.R8 控制面失效樣式 把常見攻擊結果回推成控制面失效樣式
• 2026-04-24 7.R9 攻擊者成本與行動節奏 用攻擊者成本模型判讀哪些環節最容易被優先利用
• 2026-04-24 7.R10 偵測迴避與觀測缺口 從攻擊者角度盤點偵測盲區與觀測資料缺口
• 2026-04-24 7.R7.M 案例引用地圖（服務主題 -> 案例 -> workflow） 把服務主題連到完整案例體系，再連回 incident workflow 檢查點
• 2026-04-24 7.R11.1 邀請流程濫用 說明邀請流程為何容易形成身份擴散與越權入口
• 2026-04-24 7.R11.2 審核流程濫用 說明審核節點為何會變成形式審核，進而放大高風險操作
• 2026-04-24 7.R11.3 代理操作濫用 說明代理操作為何容易形成責任鏈斷點與高權限濫用
• 2026-04-24 7.R11.4 帳號切換濫用 說明多帳號切換為何容易形成會話混層與身份擴散
• 2026-04-24 7.R11.5 密碼重設流程濫用 說明密碼重設流程為何常成為身份接管入口
• 2026-04-24 7.R11.6 權限提升流程濫用 說明權限提升流程為何容易把局部存取轉成全域控制
• 2026-04-24 7.R11.7 方案升降級流程濫用 說明方案切換流程為何容易成為權限與資源邊界繞過點
• 2026-04-24 7.R11.8 匯出流程濫用 說明匯出流程為何常被放大為資料外送主路徑
• 2026-04-24 7.R11.9 分享流程濫用 說明分享流程為何容易把內部資料邊界轉成外部可達邊界
• 2026-04-24 7.R11.10 批次操作濫用 說明批次操作為何容易放大單次權限失效的影響半徑
• 2026-04-24 7.R11.11 跨租戶協作濫用 說明跨租戶協作為何容易形成租戶邊界滲漏
• 2026-04-24 7.R11.12 第三方授權濫用 說明第三方授權流程為何容易成為供應商事件傳導節點
• 2026-04-24 7.R11.P1 可重放邀請連結 說明邀請連結重放如何把一次性流程轉成持續可利用入口
• 2026-04-24 7.R11.P2 提交與審核責任重疊 說明提交與審核責任重疊如何讓審核退化為形式流程
• 2026-04-24 7.R11.P3 代理會話上下文混層 說明代理會話與原始會話混層如何放大高權限濫用風險
• 2026-04-24 7.R11.P4 帳號切換後沿用高權限 token 說明帳號切換後權限 token 殘留如何造成身份邊界漂移
• 2026-04-24 7.R11.P5 重設憑證可重放且有效期過長 說明密碼重設憑證可重放與長時效如何形成身份接管窗口
• 2026-04-24 7.R11.P6 權限提升缺乏時效綁定 說明權限提升缺乏時效綁定如何把例外能力轉成常態能力
• 2026-04-24 7.R11.P7 降級後能力回收延遲 說明方案降級後能力回收延遲如何造成授權邊界漂移
• 2026-04-24 7.R11.P8 匯出檔案長時間可重複下載 說明匯出產物長時效與可重複下載如何放大資料外送風險
• 2026-04-24 7.R11.P9 分享連結缺少到期語意 說明分享連結缺少到期語意如何把協作路徑轉成長尾暴露路徑
• 2026-04-24 7.R11.P10 批次流程缺少中止檢查點 說明批次流程缺少中止檢查點如何放大單次失效衝擊
• 2026-04-24 7.R11.P11 跨租戶上下文快取殘留 說明跨租戶上下文快取殘留如何造成租戶邊界滲漏
• 2026-04-24 7.R11.P12 第三方 token 授權範圍過寬 說明第三方 token 授權範圍過寬如何放大供應商事件傳導
• 2026-04-24 7.R7.1.1 Uber 2022：MFA 疲勞與內部工具擴散 從社交工程到內部工具存取，拆解身分流程與權限邊界的失效點
• 2026-04-24 7.R7.1.2 Okta + Cloudflare 2023：支援流程與身分供應鏈 支援工單與第三方身份供應商路徑如何變成入侵鏈的一部分
• 2026-04-24 7.R7.1.3 Twilio 2022：社交工程與員工帳號路徑 社交工程如何穿透員工身分流程，並影響下游客戶與供應鏈
• 2026-04-24 7.R7.1.4 MGM 2023：身分流程被打穿後的營運中斷 社交工程造成身分邊界失守後，如何演變成可用性與營運衝擊
• 2026-04-24 7.R7.1.5 Microsoft Storm-0558 2023：簽章金鑰鏈與郵件存取 從簽章金鑰保護失效到雲端郵件存取，拆解身分信任鏈的關鍵控制點
• 2026-04-24 7.R7.1.6 Cloudflare 2023：供應商事件後的身分收斂 同一條供應商事件鏈，如何在客戶端變成 session 與 token 的收斂壓力
• 2026-04-24 7.R7.1.7 Slack 2022：企業 token 與程式碼資產路徑 員工帳號被社交工程利用後，企業 token 與私有程式碼資產的防線如何運作
• 2026-04-24 7.R7.1.8 Dropbox 2022：釣魚入侵與程式碼倉儲風險 從員工釣魚事件到私有程式碼資產保護，建立身分與研發資產的聯防流程
• 2026-04-24 7.R7.2.1 SolarWinds 2020：更新鏈被濫用 合法更新流程遭植入後，攻擊者如何長期潛伏與橫向擴散
• 2026-04-24 7.R7.2.2 GitHub OAuth 2022：第三方 token 供應鏈風險 第三方整合 token 被竊後，如何形成跨組織存取風險
• 2026-04-24 7.R7.2.3 CircleCI 2023：CI secrets 輪替壓力 工程端點入侵後，CI 平台 secrets 如何成為高風險擴散點
• 2026-04-24 7.R7.2.4 XZ Backdoor 2024：開源供應鏈長期滲透 開源維護鏈遭滲透後，為何會直接影響廣泛 Linux 發行流程
• 2026-04-24 7.R7.2.5 TeamCity 2023：CI 入口漏洞與交付鏈風險 CI 平台入口被利用後，如何沿著建置與發佈流程擴散供應鏈風險
• 2026-04-24 7.R7.2.6 ScreenConnect 2024：RMM 平台入口與下游擴散 遠端管理平台入口被利用後，服務商與客戶環境會同步承壓
• 2026-04-24 7.R7.2.7 Log4Shell 2021：共用元件風險與修補鏈 共用元件漏洞如何同步影響多服務，並迫使團隊建立依賴治理 workflow
• 2026-04-24 7.R7.2.8 3CX 2023：桌面軟體更新鏈攻擊 合法更新流程被植入後，桌面端供應鏈事件如何傳到企業端點
• 2026-04-24 7.R7.2.9 Kaseya VSA 2021：MSP 供應鏈擴散路徑 管理平台事件透過 MSP 模型向多客戶擴散時，workflow 應如何分層應對
• 2026-04-24 7.R7.3.1 MOVEit 2023：外網檔案服務批量外送 MFT 對外入口在零時差事件中如何被批量利用
• 2026-04-24 7.R7.3.2 Ivanti 2024：CVE-2023-46805/2024-21887 VPN 邊界漏洞鏈 多漏洞串接下，邊界設備事件如何轉為持續控制風險
• 2026-04-24 7.R7.3.3 Citrix Bleed 2023：會話被劫持與重放風險 邊界設備會話資料外洩後，如何演變成帳號與服務風險
• 2026-04-24 7.R7.3.4 PAN-OS 2024：邊界設備遠端命令執行 邊界設備 RCE 事件如何迫使團隊在修補與營運可用性間快速取捨
• 2026-04-24 7.R7.3.5 PaperCut 2023：認證繞過與入口執行風險 管理平台入口若被認證繞過，內部列印與服務節點會暴露在遠端控制風險
• 2026-04-24 7.R7.3.6 Confluence 2022：網站入口 RCE 與知識系統風險 協作平台外網入口被打穿時，內部知識與憑證線索會同步外露
• 2026-04-24 7.R7.3.7 Cisco IOS XE 2023：Web UI 管理面風險 網通設備管理介面暴露時，攻擊可直接穿透邊界控制平面
• 2026-04-24 7.R7.3.8 Fortinet SSL-VPN 2024：邊界 VPN 高風險窗口 VPN 邊界漏洞發生時，入口隔離與修補節奏需要同時啟動
• 2026-04-24 7.R7.3.9 SysAid 2023：ITSM 入口與維運流程風險 ITSM 服務入口被利用後，維運流程會成為擴散加速器
• 2026-04-24 7.R7.4.1 LastPass 2022：備份路徑與鏈式入侵 開發環境資訊外流如何沿著備份路徑擴大成資料風險
• 2026-04-24 7.R7.4.2 Snowflake 2024：憑證濫用與資料竊取 外洩憑證與 MFA 缺口如何在資料平台形成高風險外送事件
• 2026-04-24 7.R7.4.3 Change Healthcare 2024：資料事件轉為營運中斷 醫療支付中樞事件如何同時衝擊資料安全與業務連續性
• 2026-04-24 7.R7.4.4 Mailchimp 2023：支援工具路徑與客戶資料風險 社交工程進入客服工具後，如何形成特定客戶資料存取風險
• 2026-04-24 7.R7.4.5 VMware ESXiArgs 2023：虛擬化平台勒索回復壓力 虛擬化平台漏洞被利用後，回復策略與營運連續性會面臨同步壓力
• 2026-04-24 7.R7.4.6 Progress WS_FTP 2023：檔案服務入口與資料外送 對外檔案服務漏洞在企業環境常直接轉為資料外送風險
• 2026-04-24 7.R7.4.7 GoAnywhere MFT 2023：傳輸中樞被利用的外送鏈 MFT 中樞服務漏洞會把檔案交換流程直接轉成資料外送風險
• 2026-04-24 7.R7.2.10 TeamCity 2024：CVE-2024-27198/27199 入口鏈 TeamCity 連續漏洞揭示 CI 平台入口繞過與路徑穿越的供應鏈風險
• 2026-04-24 7.R7.3.10 Juniper 2023：網通設備鏈式漏洞窗口 鏈式漏洞出現在核心網通設備時，修補與流量穩定性需要同步決策
• 2026-04-24 7.R7.3.11 ServiceNow 2024：企業平台入口風險 企業核心平台漏洞出現時，服務流程與資料流程都需要同步收斂
• 2026-04-24 7.R7.3.12 Check Point 2024：VPN 資訊外洩與會話風險 邊界設備資訊外洩漏洞可快速轉為憑證與會話濫用風險
• 2026-04-24 7.R7.3.13 ProxyLogon 2021：CVE-2021-26855/27065 入口鏈式失效 郵件系統入口漏洞被串接利用時，事件會迅速擴大到內部服務邊界
• 2026-04-24 7.R7.3.14 ProxyShell 2021：CVE-2021-34473/34523/31207 後續鏈式攻擊 同類入口平台在後續漏洞波次中，如何建立持續修補與驗證機制
• 2026-04-24 7.R7.3.15 FortiOS 2022：VPN 零時差事件節奏 邊界設備零時差事件需要隔離、輪替、復測的完整鏈條
• 2026-04-24 7.R7.3.16 Citrix ADC 後續事件：Session 重放延伸 同一波邊界事件在後續通報階段，重點轉為會話與憑證收斂
• 2026-04-24 7.R7.3.17 Confluence 2023：CVE-2023-22515/22518 權限控制鏈 Confluence 權限控制弱點在連續漏洞波次中如何擴大入口風險
• 2026-04-24 7.R7.3.18 Citrix 2023：CVE-2023-3519 邊界代碼注入 NetScaler 邊界入口代碼注入事件揭示管理平面快速失守風險
• 2026-04-24 7.R7.3.19 F5 BIG-IP 2023：CVE-2023-46747 認證繞過 BIG-IP 組態管理入口認證繞過如何放大邊界設備治理壓力
• 2026-04-24 7.R7.3.20 Fortinet 2022：CVE-2022-40684 認證繞過 Fortinet 多產品認證繞過事件反映邊界與管理面共享風險
• 2026-04-24 7.R7.3.21 Fortinet 2023：CVE-2023-27997 SSL-VPN 溢位 SSL-VPN 漏洞在邊界設備上會放大大規模掃描與利用速度
• 2026-04-24 7.R7.3.22 FortiClient EMS 2023：CVE-2023-48788 SQL 注入 端點管理平台 SQL 注入事件揭示管理平面資料與權限風險
• 2026-04-24 7.R7.3.23 ManageEngine 2021：CVE-2021-40539 認證繞過 身分服務入口認證繞過會把帳號管理流程直接暴露在攻擊鏈上
• 2026-04-24 7.R7.3.24 USAHERDS 2021：CVE-2021-44207 硬編碼憑證 硬編碼憑證事件展示供應商系統配置治理與存取控制的共同風險
• 2026-06-16 Firestore Distributed Counter Lab 在 emulator 上實作 distributed counter：建立 N 個 shard、隨機分片寫入、觀察 shard 分佈是否均勻、讀取彙總驗證總和正確，並說明 contention 本身是 emulator 不模擬的 production 特性
• 2026-06-16 Firestore Local Emulator Quickstart 用 Firebase CLI 啟動 Firestore emulator、寫 firestore.rules、用 admin SDK seed 資料、跑 query baseline 與 cleanup，建立後續 Security Rules 與 distributed counter lab 共用的本地環境
• 2026-06-16 Firestore Security Rules Test Lab 用 @firebase/rules-unit-testing 在 emulator 上把 Security Rules 寫成自動化測試：放行 / 越權拒絕 / 未登入拒絕 / 欄位竄改拒絕四類斷言、firebase emulators:exec 在 CI 跑、把規則測試接進 release gate
• 2026-05-22 Aurora PostgreSQL I/O-Optimized Cost Aurora PostgreSQL Standard 與 I/O-Optimized 的成本模型、I/O 壓力、workload 判斷、遷移與回退條件
• 2026-05-22 Managed PostgreSQL Comparison RDS PostgreSQL、Aurora PostgreSQL、Cloud SQL、Azure Database for PostgreSQL、Neon、Supabase、Crunchy Bridge 的責任邊界比較
• 2026-05-22 MySQL Audit Log + SIEM MySQL audit log、general log、slow log、privilege event、SIEM pipeline、retention 與 alert route
• 2026-05-22 MySQL Backup Restore Drill MySQL logical dump、physical backup frame、binlog position、restore validation 與 RPO / RTO evidence
• 2026-05-22 MySQL Cross-buffer Memory Contention MySQL InnoDB buffer pool、sort / join buffer、tmp table、thread memory、OS page cache 與 memory pressure 判讀
• 2026-05-22 MySQL Document Store / X Protocol MySQL Document Store、X Protocol、JSON collection、SQL interoperability、MongoDB-like API 與使用邊界
• 2026-05-22 MySQL Encryption / TLS / Key Management MySQL at-rest encryption、TLS、keyring、certificate rotation、backup encryption 與 credential governance
• 2026-05-22 MySQL HeatWave OLAP Add-on MySQL HeatWave、OLTP + OLAP hybrid、query offload、cost model、data freshness 與 warehouse 邊界
• 2026-05-22 MySQL Local Lab Quickstart MySQL local lab 的 Docker Compose、schema seed、sample workload、basic metric 與 teardown
• 2026-05-22 MySQL Metadata Lock Deep Dive MySQL metadata lock、DDL blocking、long transaction、online schema change、MDL observability 與 incident runbook
• 2026-05-22 MySQL Multi-source Replication MySQL multi-source replication、channel、consolidation、conflict boundary、lag monitoring 與 migration route
• 2026-05-22 MySQL Online Schema Change Lab MySQL ALTER TABLE、metadata lock、gh-ost / pt-osc frame、cutover evidence 與 rollback note
• 2026-05-22 MySQL ProxySQL Routing Lab MySQL ProxySQL hostgroup、read/write split、query rule、backend health 與 routing evidence
• 2026-05-22 MySQL Replication Failover Lab MySQL source / replica、replication lag、promotion、client route、Orchestrator frame 與 validation evidence
• 2026-05-22 MySQL Vitess Sandbox Route Vitess sandbox、keyspace、shard、VSchema、query routing、resharding preview 與 MySQL migration evidence
• 2026-05-22 PostgreSQL Connection Pool Lab PostgreSQL application pool、PgBouncer、backend connection、pool exhaustion 與 failover reconnect 的操作說明
• 2026-05-22 PostgreSQL Connection Pooler Comparison PostgreSQL PgBouncer、Odyssey、RDS Proxy、application pool 與 transaction pooling 的選型比較
• 2026-05-22 PostgreSQL Cross-region DR PostgreSQL 跨區災難復原、physical replica、logical replication、backup restore、RPO / RTO 與 failover runbook
• 2026-05-22 PostgreSQL Developer / DBA Responsibility Split PostgreSQL application developer、DBA、platform team 在 schema、query、migration、backup、incident 與 capacity 的責任分工
• 2026-05-22 PostgreSQL HA Failover Drill PostgreSQL Patroni 或 managed failover 的 promotion、client reconnect、pooler behavior 與 incident timeline
• 2026-05-22 PostgreSQL Local Lab Quickstart PostgreSQL local lab 的 Docker Compose、schema seed、sample workload、basic metric 與 teardown
• 2026-05-22 PostgreSQL Logical Decoding Plugins PostgreSQL logical decoding output plugin、pgoutput、wal2json、test_decoding、CDC connector 與 plugin 選型
• 2026-05-22 PostgreSQL pg_partman Advanced PostgreSQL pg_partman 自動分區、premake、retention、maintenance job、partition migration 與 runbook
• 2026-05-22 PostgreSQL PITR Restore Drill PostgreSQL base backup、WAL archive、target time restore、validation query 與 RPO / RTO evidence 的操作說明
• 2026-05-22 PostgreSQL Schema Migration Evidence Lab PostgreSQL expand / contract migration、validation query、rollback condition 與 release gate evidence 的操作說明
• 2026-05-22 PostgreSQL Security / RLS / Audit Logging PostgreSQL role、grant、Row Level Security、pgAudit、log policy、PII access evidence 與合規路由
• 2026-05-22 PostgreSQL to YugabyteDB / TiDB Migration PostgreSQL 轉向 YugabyteDB、TiDB 類 distributed SQL 的 compatibility audit、data topology、transaction、cutover 與 rollback
• 2026-05-22 Specialized PostgreSQL Variants pgvectorscale、Citus、TimescaleDB、PostGIS、AlloyDB、Cosmos DB for PostgreSQL、serverless PG 等 PostgreSQL 變體的選型邊界
• 2026-05-21 PostgreSQL to SQLite Simplification PostgreSQL 降低操作成本轉向 SQLite 的適用條件、資料責任縮小、export/import、runbook 與 no-go condition
• 2026-05-21 SQLite Backup Restore Drill SQLite .backup、VACUUM INTO、restore validation、sidecar file handling 與 RPO / RTO note 的操作說明
• 2026-05-21 SQLite D1 / Turso / libSQL Comparison Cloudflare D1、Turso、libSQL 與 local SQLite 在 edge、replication、consistency、migration 與 vendor boundary 的比較
• 2026-05-21 SQLite D1 / Turso Preview Lab SQLite local DB 匯出到 Cloudflare D1 或 Turso preview environment 的 compatibility、latency 與 rollback 操作說明
• 2026-05-21 SQLite file lifecycle 與 backup boundary 把 SQLite 單檔案正式狀態拆成 WAL、backup API、restore drill、corruption recovery 與操作責任邊界
• 2026-05-21 SQLite Litestream / LiteFS Replication Litestream、LiteFS、SQLite backup replication、read replica、failover 與 restore route
• 2026-05-21 SQLite Local File Quickstart SQLite local .db file、schema、seed data、PRAGMA baseline、query sample 與 cleanup 的操作說明
• 2026-05-21 SQLite Local-first Sync Boundary SQLite local-first app、multi-device sync、server authority、conflict resolution、delete propagation 與 offline-first trade-off
• 2026-05-21 SQLite Migration Fixture Lab SQLite user_version、table rebuild migration、fixture snapshot、rollback note 與 CI evidence 的操作說明
• 2026-05-21 SQLite Mobile / Desktop Embedded Store SQLite 在 mobile、desktop、CLI、browser profile 與 embedded device 中承擔 local formal state 的資料責任、backup、privacy 與 sync boundary
• 2026-05-21 SQLite Observability and Runbook SQLite production runbook、backup evidence、WAL growth、busy errors、disk usage、restore drill 與 incident route
• 2026-05-21 SQLite PRAGMA Tuning and Performance SQLite journal_mode、synchronous、busy_timeout、wal_autocheckpoint、cache_size、mmap_size、auto_vacuum 與 performance evidence 的操作判準
• 2026-05-21 SQLite Schema Migration and Versioning SQLite schema migration、user_version、table rebuild、ALTER TABLE 限制、app release compatibility 與 migration evidence
• 2026-05-21 SQLite SQL Dialect and Index Limits SQLite type affinity、NULL / date handling、constraint、index、query planner 與 PostgreSQL / MySQL 差異
• 2026-05-21 SQLite Teaching Structure SQLite 服務章節群的大綱：從 embedded formal state、WAL、backup、test fixture、local-first、edge SQLite 到遷移路由
• 2026-05-21 SQLite Test Fixture Best Practice SQLite 作為 test fixture、repository contract test、production dialect gap、seed data、fixture snapshot 與 CI evidence 的操作判準
• 2026-05-21 SQLite to D1 / Turso Migration SQLite 轉向 Cloudflare D1、Turso / libSQL 的 edge driver、compatibility audit、data movement 與 rollback
• 2026-05-21 SQLite to PostgreSQL Migration SQLite 升級到 PostgreSQL 的 driver、schema diff、data copy、dual run、cutover、rollback 與 cleanup
• 2026-05-21 SQLite WAL Busy Reproduction SQLite long transaction、SQLITE_BUSY、busy_timeout、checkpoint growth 與 writer queue 的操作說明
• 2026-05-21 SQLite WAL Concurrency and Locking SQLite WAL mode 如何降低 reader / writer 衝突、保留 single writer boundary，並用 SQLITE_BUSY、WAL growth、checkpoint 訊號判斷 production 上限
• 2026-05-20 資料庫 Vendor 文章撰寫規格 把 PostgreSQL 與 MySQL batch 的正文經驗整理成資料庫 vendor overview、deep article 與 migration playbook 的撰寫規格
• 2026-05-19 Atlassian Statuspage → Instatus：status page 成本下降、但 compatibility audit 不能跳 Atlassian Statuspage → Instatus 是 Type B drop-in migration、6 維 audit 全 Low；典型情境是從 Statuspage Business / Enterprise 降到 Instatus Pro / Business、但 savings 取決於 subscriber、SSO、audit 與 SLA report 需求。本文走 compatibility audit prefix（subscriber channel 完整度 / SAML SSO / audit log / metrics integration / SLA report / API parity）、4 階段 cutover（DNS TTL + parallel run）、5 個 production 踩雷（SSO tier 選錯、metrics 來源整合斷、subscriber import format / SLA report 缺、custom CSS 不完全相容）、何時不要切（enterprise compliance / 強 Atlassian 整合）
• 2026-05-19 JMeter → k6：k6 不是 JMeter 的「script 版本」、是 VU model 取代 thread model JMeter → k6 是 Type E paradigm shift、不是把 .jmx XML 翻成 JavaScript — VU (virtual user) model 跟 thread group model 是兩種對「使用者行為」不同的建模方式。本文走 6 維 audit（Schema High / Paradigm High / Operational Medium）、釐清反向定義、4-phase partial migration（多數 org 停 Phase 2-3 hybrid）、5 production 踩雷（thread group 翻譯失真 / arrival rate vs concurrent VU 混淆 / protocol gap / 結果 schema 改 / CI integration 重做）、protocol gap（JDBC / JMS / LDAP 在 k6 沒原生對應）、何時不要切
• 2026-05-19 PagerDuty → incident.io：「On-call」是個 retconned word、同名不同 contract PagerDuty → incident.io 不是 schema translation — 兩家的「on-call」字面相同、contract 不同（alert routing vs IR coordination + Slack-native + retrospective）。本文走 Type E paradigm shift、6 維 audit 顯示 paradigm / schema / operational 三軸 High、用 4-phase partial migration（不收斂、Phase 1-2 多數 org 停留）、5 個 production 踩雷（雙系統 state drift / severity 翻譯失真 / schedule layer 漏 / Slack channel 過載 / retrospective 斷層）、跟 PagerDuty Process Automation / AIOps 沒對應的 capability gap
• 2026-05-19 PagerDuty → Opsgenie：Atlassian 全家桶整合 vs Opsgenie 2027 EOL 的 vendor consolidation 取捨 PagerDuty → Opsgenie 是 Type A phased schema translation、但 Atlassian 已宣布 Opsgenie 2027-04 EOL — 這條 migration 只在 Atlassian-heavy org + 明確 JSM unification roadmap 下成立、本質是 PD → Opsgenie → JSM Cloud 的雙 hop migration。本文走 6 維 audit（Schema Medium-High 其他 Low）、PagerDuty ↔ Opsgenie ↔ JSM field mapping 對照、5 production 踩雷（escalation step / Heartbeat 缺對應 / integration key dedup 重設 / schedule 時區 / Atlassian Identity SSO 整合）、何時直接走 PD → JSM 跳過 Opsgenie
• 2026-05-19 Pyroscope → Datadog Continuous Profiler：profiling deployment lifecycle 各階段 operational ownership 轉手 Pyroscope → Datadog Continuous Profiler 是 Type C operational hybrid migration — pprof data model 接近、profile lifecycle 五階段（install / instrument / ingest / query / cost）的 ops ownership 從 self-host 轉到 SaaS。本文走 6 維 audit（Operational High 其他 Low）、4-phase migration（operational audit + agent parallel + tag reconcile + cutover）、5 production 踩雷（agent 重複 overhead / tag schema 不一致 / trace_id correlation 斷 / cost 突增 / retention 政策變動）、何時保留 Pyroscope（資料主權 / 內網 / OSS-first / cost sensitive）
• 2026-05-18 API 認證的三層信任邊界：使用者、系統、跨系統 Provisioning API 認證的信任邊界分層（Bearer Token / Shared Secret / Provisioning）：各層的洩漏後果與撤銷方式，以及混用造成的設計失效模式。
• 2026-05-18 Shared Secret 安全輪替設計：雙密過渡期、自動化與緊急流程 系統間 Shared Secret 輪替的核心機制：dual-secret rollover、自動化工具比較（AWS Secrets Manager / Vault / GCP）、緊急 rotation 流程與多 client 環境的失敗模式。
• 2026-04-23 0.0 後端需求分類地圖 先從需求形狀辨識狀態、讀取、非同步、即時、診斷、交付與可靠性問題