可擴展性 (Scalability)
核心定義
系統能隨著需求（使用者、資料量、流量）增加，透過增加資源來維持效能與穩定性的能力。
| 指標 | 定義 | 關聯 |
|---|---|---|
| Throughput（吞吐量） | 每秒能處理的請求數（RPS） | 擴展目標：提高吞吐量 |
| Latency（延遲） | 單一請求從發出到完成的時間 | 擴展目標：降低延遲 |
為什麼重要？
使用者量成長時，若架構不可擴展 → 延遲上升、錯誤增加、甚至宕機。
可擴展架構能彈性增減資源，支撐業務成長，同時避免單點故障。
垂直擴展（Vertical Scaling）
升級單一伺服器的硬體規格：加 CPU、加 RAM、換更快的硬碟。
┌──────────┐ ┌──────────────┐
│ Server │ → │ Server │
│ 4 cores │ 升級 │ 16 cores │
│ 16 GB │ │ 64 GB RAM │
└──────────┘ └──────────────┘
舊機器 新機器
| 項目 | 說明 |
|---|---|
| 優點 | 簡單、改動少、不需要修改應用程式架構 |
| 缺點 | 有物理上限（CPU/RAM 無法無限升級）；停機風險；初期便宜但後期貴 |
| 適合 | 短期快速解法、流量剛開始成長時 |
水平擴展（Horizontal Scaling）
增加伺服器數量，透過 Load Balancer 分擔流量。
┌──────────┐
┌──► Server 1 │
Client → LB ──┤ └──────────┘
├──► Server 2 │
│ └──────────┘
└──► Server 3 │
└──────────┘
| 項目 | 說明 |
|---|---|
| 優點 | 理論上無限擴展；彈性佳；高可用性（一台掛掉不影響服務） |
| 缺點 | 設計複雜；需處理分散式資料一致性；需要 Load Balancer |
| 適合 | 長期、大規模成長；需要高可用性的系統 |
垂直 vs 水平比較
| 比較項目 | Vertical Scaling | Horizontal Scaling |
|---|---|---|
| 做法 | 升級單機規格 | 增加機器數量 |
| 上限 | 有物理上限 | 理論無限 |
| 複雜度 | 低 | 高（需 LB、分散式一致性） |
| 成本 | 初期低、後期貴 | 彈性，按需付費 |
| 停機風險 | 升級時可能需停機 | 可滾動更新，無停機 |
| 典型時機 | 短期、快速解法 | 長期、大規模 |
面試策略
先垂直，再水平。
流量初期用垂直擴展應急，等到碰到硬體上限或需要高可用性時，才轉向水平擴展。
面試中直接說「我們先垂直擴展，之後再水平」是合理且常見的答案。
水平擴展的挑戰
不是加機器就好
水平擴展帶來的新問題：
- Session 狀態：請求可能打到不同 Server，Sticky Session 或集中式 Session Store
- 資料一致性：多台 Server 後的 DB 如何同步？→ 見 02-Distributed-Systems/02-CAP-Theorem
- Load Balancer 本身的 SPOF：需要 LB 也要做高可用（主備/多節點）
- 資料分片（Sharding）：資料量大時，DB 也要水平擴展