系統設計與品質標準
從需求收集到架構設計到品質檢查表。「怎麼做出好的系統」的完整方法論。
系統規劃
API 設計
Proto 規劃
- Proto 規劃（一）：為什麼重新發明輪子
- Proto 規劃（二）：完整性檢查
- Proto 規劃（三）：前後端 App 各自需求
- Proto 規劃（四）：Gap Analysis
- Proto 規劃（五）：多語言
好產品的定義
設計工具與方法
需求與估算方法論
- 需求訪談方法論：want vs need 區分、User Story + Acceptance Criteria
- 非功能性需求（NFR）完整清單：Latency / Throughput / Reliability / PACELC，SLO / SLA / Error Budget
- 系統設計面試框架：5 階段（需求澄清 → back-of-envelope → 高層架構 → 深入設計 → 進階討論）
分散式系統基礎
概念層，不是 pattern（在 C04）也不是運維（在 infra I04）——是「為什麼分散式系統難」的底層邏輯。
- CAP Theorem 深入 — 解決的問題：你有多個節點，網路可能中斷，partition 發生時要繼續服務（AP）還是拒絕服務保一致（CP）？CAP 說明這兩件事不可兼得。etcd 選 CP（etcd 不一致就 Kubernetes cluster 壞了），Cassandra 選 AP（讀到舊資料比服務中斷更可接受）。PACELC 延伸解釋正常時的 latency vs consistency 取捨。
- Paxos） — 解決的問題：多個節點如何就「誰是 leader」「這筆 write 算不算 committed」達成一致——沒有 consensus，任意節點都可以自稱 leader，資料就分裂了（split-brain）。Raft 是 etcd / ZooKeeper / Consul 底層能夠自動選 leader、node 掛掉後自動恢復的機制。Paxos 更早但複雜，Raft 以可理解性為設計目標。
- Logical Clock — 解決的問題：兩個節點各自做了修改，時間戳無法判斷誰先（機器時鐘不同步，NTP 誤差幾百毫秒）。Lamport Clock 用「邏輯計數器」代替物理時間；Vector Clock 進一步能判斷「這兩個更新是有因果關係的，還是並發的（需要衝突解決）」。Amazon DynamoDB、Riak 用 Vector Clock 偵測 replica 之間的衝突。
- Eventual Consistency 分類 — 解決的問題：Strong consistency 需要所有副本同步（延遲高），Eventual Consistency 又太模糊（多久是「最終」？能不能讀到自己剛寫的？）。這篇把 EC 從弱到強分 5 層，讓你能說出「我們需要 Read-your-writes，不需要 Linearizability」，而不是一句「eventual consistency 就好」草草帶過。
- 分散式系統常見失敗模式 — 解決的問題：為什麼 1994 年寫的 8 條 Fallacies 到 2024 年還在被違反？因為人類直覺是單機的，而分散式的反直覺坑（網路不可靠、延遲不為零、拓撲不固定）每一代工程師都會重踩。這篇是你第一次設計分散式系統前的地雷地圖。
- 系統設計 Anti-patterns — 解決的問題：為什麼一個設計 review 通過了，到 production 還是出問題？通常是設計過程本身有缺陷：跳過估算所以不知道量級、誤以為能同時保 CAP 三個、為了 microservice 而拆 microservice 帶來分散式 transaction 複雜度卻沒有規模上的收益。
品質標準檢查表（已搬至 standards/）
「好的 X 該有什麼」系列已搬到 standards，因主詞是「專案 / 系統」不是「設計方法論」，不適合留在 system-design/。
延伸閱讀
壓測數據驅動的系統設計決策，見 微服務之旅系列