主從架構 (Client-Server Architecture)
核心模型
幾乎所有系統設計面試的起點。Client 發起請求，Server 處理並回應。
┌──────────┐ Request ┌──────────────────────────────┐
│ Client │ ────────────► │ Server │
│ │ ◄──────────── │ ├── Web Server (Nginx) │
└──────────┘ Response │ ├── App Server (Node/Django) │
│ └── Database (PostgreSQL) │
└──────────────────────────────┘
| 角色 | 核心職責 | 常見例子 |
|---|---|---|
| Client | 呈現 UI、收集輸入、發送請求、展示回應 | 瀏覽器、手機 App、桌面應用、微服務 |
| Server | 驗證授權、執行商業邏輯、讀寫 DB、回傳結果 | Nginx, Django, PostgreSQL |
為什麼重要？
- 職責分離：Client 負責展示，Server 負責邏輯和資料 → 各自獨立維護和更新
- 集中管理：邏輯和資料在 Server 端，安全可控，Client 無需知道內部細節
- 多 Client 支援：同一 Server 可同時服務網頁、App、第三方 API
- 擴展基礎：流量增大時只需擴展 Server，不用改動 Client → 見 02-Distributed-Systems/03-Scalability
Thin Client vs Thick Client
| 類型 | 邏輯位置 | 例子 | 優點 | 缺點 |
|---|---|---|---|---|
| Thin Client | Server 端 | 傳統 SSR 網頁 | 輕量、安全（邏輯不暴露） | 每次互動需請求，體驗較慢 |
| Thick Client | Client 端 | React SPA、手機 App | 體驗流暢、減少 Server 負擔 | 前端複雜，邏輯部分暴露 |
面試預設
現代系統設計預設 Thick Client（SPA / 手機 App） + RESTful API。
設計重點在 Server 架構，但 Client 類型影響 API 設計風格。
Client-Server vs Peer-to-Peer（P2P）
| 特性 | Client-Server | P2P |
|---|---|---|
| 通訊方式 | Client → Server 請求 | 節點間直接溝通 |
| 集中控制 | 有（Server 控制） | 無（去中心化） |
| 擴展方式 | 擴展 Server | 加入更多 Peer |
| 典型應用 | 幾乎所有 Web 應用 | 音視訊通話（WebRTC）、BitTorrent |
面試陷阱
系統設計面試 99% 是 Client-Server。
只有明確涉及音視訊通話才考慮 P2P（WebRTC）。→ 見 01-Networking/05-Realtime-Protocols
面試畫圖起手式
1. Client：使用者用什麼介面？（瀏覽器？App？）
↓
2. Server：處理請求的後端服務
↓
3. API：如何溝通？（REST？WebSocket？）
↓
4. Database：資料存哪？
↓
5. 擴展：流量大了 → Load Balancer → Cache → CDN
這是你畫的第一條線
Client-Server 是所有後續設計的框架，後續的 LB、Cache、DB Sharding 都是在這個基礎上展開的。
Related Notes
- 02-Distributed-Systems/03-Scalability — 擴展 Server 的兩種方式
- 02-Distributed-Systems/02-CAP-Theorem — 分散式 Server 的一致性取捨
- 01-Networking/06-Load-Balancing — 多台 Server 前的流量分配
- 01-Networking/05-Realtime-Protocols — P2P（WebRTC）vs Client-Server
- 01-Networking/04-API-Paradigms — Client-Server 間的 API 選型
- 02-Distributed-Systems/Practice-Distributed-Systems