系統設計思維：
從需求分解到架構決策

為什麼系統設計「感覺很難」？

系統設計難不在於技術本身，而在於它沒有固定答案。 演算法題有正確解，系統設計題是在模糊需求下做取捨。 初學者最常犯的錯誤有三個：

Step 1：需求釐清（Requirements Clarification）

永遠是第一步，花 5 分鐘在這裡，能省 30 分鐘的冤枉路

面試官說「設計 URL Shortener」，這個描述至少有十種不同的系統。 在設計之前，你需要問到兩類需求：

Step 2：容量估算（Capacity Estimation）

「大概」的數字比沒有數字好，數量級對了就夠了

估算的目的不是精確，而是判斷架構規模： 一台機器夠不夠？需不需要分片？需不需要快取？ 先記住幾個常用數字：

Step 3：高層架構設計（High-Level Design）

先畫方塊圖，再說每個方塊的職責

估算結果是架構的「輸入」，不是終點。 12K QPS 告訴你需要快取；36TB 告訴你需要分片——這些數字現在要轉換成具體的元件與資料流。 高層架構設計的原則是：先確認誰負責什麼，再討論怎麼做。

注意這個架構把讀寫分離成兩個服務（Write Service / Read Service）。 這是因為我們算出讀取是 12K QPS，但寫入只有 115 QPS——兩者規模差一百倍， 分開設計讓各自可以獨立擴縮（Scale Out）。

Step 4：深入關鍵模組

面試官通常會指定一個模組讓你深入

以 URL Shortener 為例，最值得深入的是「短碼生成策略」。 這看起來簡單，但真正做到不重複、高可用，有幾種思路：

// MD5 前 7 碼
const shortCode = md5(originalUrl).slice(0, 7);
// 問題：碰撞時如何處理？遞增後綴直到不衝突

// DB 自增 ID → Base62
function toBase62(id: number): string {
  const chars = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
  let result = '';
  while (id > 0) {
    result = chars[id % 62] + result;
    id = Math.floor(id / 62);
  }
  return result;
}

// Snowflake ID: 64 bits
// [1 bit 符號][41 bit 時間戳][10 bit 機器 ID][12 bit 序列號]
// 可每毫秒產生 4096 個不重複 ID，不需中央協調

通用系統設計框架（可套用任何題目）

必知的系統設計取捨

重點整理