目錄
Martin Kleppmann 的《Designing Data-Intensive Applications》（DDIA）是目前系統設計領域最重要的工程書籍之一。第一章只有幾十頁，但它定義了整本書的思考框架——一個讓你能清醒討論系統取捨的詞彙體系。
很多工程師說「我讀過 DDIA」，但他們往往跳過了第一章。這是個錯誤。
TL;DR
DDIA 第一章提出：現代資料密集型系統（data-intensive applications）的核心挑戰不是計算能力不足，而是資料的複雜性——資料量大、資料變化快、資料的種類多。評估這個複雜性的三個維度是可靠性（Reliability）、可擴展性（Scalability）、可維護性（Maintainability）。這三個詞聽起來都懂，但真正理解它們的定義會改變你的設計決策。
是什麼
「資料密集型應用」（data-intensive applications）的對立面是「計算密集型應用」（compute-intensive applications）。後者的瓶頸是 CPU 運算量，前者的瓶頸是資料本身——資料量、資料複雜度、或資料變更的速度。
Kleppmann 的觀察是：現代大部分的軟體工程問題都屬於資料密集型，而不是計算密集型。這意味著你選的技術框架和資料庫比你選的程式語言更影響系統的上限。
為什麼重要
工程師在討論系統設計時有一個普遍的問題：用日常語言討論技術取捨，導致雞同鴨講。
- 「這個系統不可靠」——是說它常常掛，還是說它偶爾回傳錯誤資料？
- 「我們需要更好的擴展性」——是要處理更多使用者、更大的資料量，還是更複雜的查詢？
- 「這段程式碼很難維護」——是說它難讀、難改、還是難部署？
DDIA 第一章的價值在於它給了這三個詞精確的定義，讓討論可以在同一個語境下進行。
怎麼運作：三個核心屬性
可靠性（Reliability）
Kleppmann 的定義不是「不會掛掉」，而是：系統在面對硬體故障、軟體 bug、和使用者操作失誤時，仍然能正確執行預期功能的能力。
這個定義的關鍵是「正確執行」——一個系統可以一直在線（high availability），但每隔一段時間回傳錯誤資料，那它是可用但不可靠的。
實現可靠性的核心方法是：在設計時假設每個元件都會故障（fault），然後設計讓系統容錯（fault-tolerant）的機制。Netflix 的 Chaos Monkey 在生產環境隨機殺掉服務，就是把「容錯設計」內建進開發流程的極端版本。
區分兩個概念：
- fault（單一元件故障）：一個節點掛了、一塊硬碟壞了
- failure（整個系統無法服務）：系統完全不可用
可靠性設計的目標是讓單一 fault 不演變成 system failure。
可擴展性（Scalability）
「系統可以擴展」不是一個有意義的陳述，因為擴展什麼沒說清楚。
Kleppmann 定義可擴展性為：當系統的負載（load）增加時，有合理的方法維持良好效能的能力。
這裡有兩個需要精確化的概念：
負載參數（load parameters）：描述系統目前承受的負載的指標。對 web 服務，可能是 requests/second；對資料庫，可能是讀寫比；對 Twitter，可能是「每個使用者的平均 follower 數」（因為它直接影響 fanout 問題的複雜度）。
效能指標：你在乎的效能到底是什麼？平均響應時間？p99 延遲？吞吐量？Kleppmann 強調要用百分位數（percentile）衡量延遲，而不是平均值——平均值會被少量的異常高延遲拉高，但 p99 告訴你最慢的那 1% 使用者的真實體驗。
可維護性（Maintainability）
這是三個屬性中最容易被低估的。Kleppmann 把可維護性拆成三個子概念：
可操作性（Operability）：運維團隊可以輕鬆地保持系統正常運行。包含：良好的監控、清楚的文件、可預測的行為、容易的版本升級。
簡單性（Simplicity）：系統的複雜度在可控範圍內，讓新加入的工程師能夠理解。Kleppmann 指出，複雜度的主要來源是意外複雜度（accidental complexity）——不是問題本身固有的複雜，而是在實作過程中不必要地引入的複雜度。
可演化性（Evolvability）：系統容易做出改變，能夠適應新的需求。這也是 Kleppmann 在整本書中反覆強調的：系統不是一次性建造的，而是持續演化的。
跟「大數據」的差別
「大數據」這個詞通常讓人聯想到 Hadoop、Spark、分散式運算。但 DDIA 第一章的框架更底層：你的系統到底難在哪裡？
有些系統資料量不大，但可靠性要求極高（金融交易系統）。有些系統資料量龐大，但讀多寫少，主要難題是查詢擴展性而不是寫入吞吐量。「大數據」技術解決的是特定的擴展性問題，不是所有的資料密集型問題。
選技術前，先明確你的系統的負載參數，以及在可靠性、可擴展性、可維護性三個維度上的實際需求——這才是 DDIA 第一章想教你的思考方式。
小結
DDIA 第一章給工程師的最大禮物不是技術知識，而是一套清醒討論系統設計的語言。當你跟同事說「這個架構不夠可擴展」，你現在知道要接著問：「什麼樣的負載增加？哪個效能指標在哪個百分位數下降了多少？」
這個精確化的習慣，比任何具體的技術選型決定都更有長期價值。
參考資料
相關標籤
相關文章
系統設計 Mock：書籍電商平台的架構決策
設計一個書籍銷售平台時，關鍵決策是搜尋架構（Elasticsearch vs 全文搜尋）、庫存一致性（強一致 vs 最終一致）、以及訂單狀態機的設計。
系統設計面試是背八股嗎？
系統設計面試的核心不是記答案，而是展示你能從 first principles 推導出設計決策的過程。背熟 Kafka、Redis、一致性雜湊沒有用；能解釋「為什麼在這個情境選這個方案、它的代價是什麼」才重要。
系統設計 Mock：DoorDash 捐贈活動的設計拆解
DoorDash 捐贈活動是一個典型的高并發、最終一致性場景：大量用戶在結帳時觸發小額捐贈，需要即時顯示滾動捐贈總計。核心設計取捨是強一致性（雙重寫入 + 2PC）vs 最終一致性（事件驅動 + counter aggregation）。