方塊圖不會在真實硬體上跑。NALSD 的「非抽象」就是逼你把白板設計一路算到真實數字——多少磁碟、多少 IOPS、多少 RAM、多少台機器——因為所有系統終究要跑在真實的電腦、資料中心和網路上。前期多算一點，通常能省下最後一刻因物理限制而被迫重來的設計變更。
🧠 Intuition
IMPORTANT
NALSD 是一種迭代式方法：從白板上的基本系統圖出發，一路把設計具體化為資源提案。它的價值不在於算出完美答案，而在於結合多個不完美但合理的估算，來更透徹地理解設計——早期假設會大幅影響計算，但完美假設從不是要求。
- 「非抽象」的核心紀律：不停在方塊圖，而是把每個元件翻成真實資源（儲存、IOPS、RAM、網路頻寬、機器數）並評估可行性。
- 設計流程分兩階段。基本設計階段問 Is it possible?（不管資源限制，能否滿足需求）與 Can we do better?（能否更快、更小、更高效）。
- 擴展階段再問 Is it feasible?（在預算、硬體等限制下是否可行）、Is it resilient?（元件或整個資料中心故障時會怎樣）與 Can we do better?。
- 迭代從最簡單的假設起步，逐步往上推：單機 → 分散式 → 分片 → 多資料中心，每一步都重新做資源計算並評估是否過關。
- 即使某一步不可行（如硬塞進單機），它仍有價值——它讓你摸清系統的物理約束，成為下一步迭代的推理依據。
⚖️ Tradeoffs
停在方塊圖 vs 算到真實數字
- 抽象方塊圖能表達「有哪些元件、怎麼連」，但無法告訴你它跑不跑得動：單機起點看似可行，一算才發現要約 2,500 個磁碟（每 HDD 200 IOPS）、約 1,563 台機器（每台 64 GB RAM）才撐得住。
- 把設計算到真實數字，才會看見隱藏約束：單台機器的 CPU、記憶體、儲存、電源、網路、散熱全是單點故障，光是一次電源重啟就嚴重影響使用者。
- 代價是前期要動筆估算、要接受假設不完美；但這正是 NALSD 主張的：早點把物理限制攤開，勝過在最後一刻被迫改設計。
單機夠用 vs 何時該分散式／分片／多資料中心
- 每一步迭代都由「資源計算是否過關」驅動：單機因 SPOF 與 RAM／IOPS 不可行 → 走向分散式（MapReduce）；但小批次處理無法滿足資料延遲 SLO，於是改用持續串流關聯的 LogJoiner 設計。
- 當某元件的資料量超過單機容量（如 QueryMap 每日約 2 TB 遠超 64 GB RAM、IOPS 也過高），就以
query_id雜湊分片，讓多個處理器並行，並用重複分片降低故障遺失風險。 - 單一資料中心託管所有分片仍是單點故障——資料中心斷線就全停；於是再迭代到多資料中心，以共識演算法跨地理複製狀態，代價是每次寫入至少一次跨節點往返的延遲。
🔑 Takeaways
- NALSD 的「非抽象」是核心紀律：把白板設計一路算到真實資源數字並評估可行性，而不是停在方塊圖。
- 設計靠兩階段、四個關鍵問題（possible／better／feasible／resilient）反覆驅動，從單機逐步迭代到分散式、分片、多資料中心。
- 每一步都做「資源計算＋可行性評估」，即使不可行的步驟也提供推理系統約束的寶貴資訊；這是需要定期練習維持的技能。
No notes yet — jot your takeaways or Q&A here.