這部影片由 AlgoMaster 頻道製作，整理了系統設計中最重要的 30 個核心概念。從最基礎的 Client-Server 架構、DNS、HTTP 協議，到進階的資料庫擴展策略（Replication、Sharding）、快取、CDN、微服務與訊息佇列，涵蓋了系統設計面試和實際工程中反覆出現的關鍵知識。作者以自身在大型科技公司 8 年的經驗為基礎，將這些概念串聯成一個完整的學習路徑。

原影片連結：https://www.youtube.com/watch?v=s9Qh9fWeOAk

影片重點

• Client-Server 架構是幾乎所有 Web 應用的基礎模型
• DNS 將人類可讀的域名轉換為 IP 位址
• Proxy 與 Reverse Proxy 在系統中扮演不同角色
• HTTP/HTTPS 是客戶端與伺服器溝通的標準協議
• REST 和 GraphQL 是兩種主流的 API 設計風格
• SQL 和 NoSQL 各有適用場景，現代應用常混合使用
• 垂直擴展有上限，水平擴展才是長期方案
• 資料庫擴展有四大技術：Indexing、Replication、Sharding、Denormalization
• 快取（Caching）和 CDN 是提升效能的關鍵手段
• 微服務架構搭配 Message Queue 實現服務解耦

詳細內容

[00:00] Client-Server 架構

幾乎所有你使用的 Web 應用都建立在 Client-Server 架構之上。客戶端（Client）可以是瀏覽器、行動 App 或任何前端應用；伺服器（Server）則是一台持續運行的機器，等待處理傳入的請求。客戶端發送請求來儲存、讀取或修改資料，伺服器接收請求後進行處理，並回傳回應。

[01:10] IP 位址與 DNS

客戶端如何找到伺服器？在網路上，電腦透過 IP 位址互相識別，就像伺服器的電話號碼。但我們造訪網站時不會輸入 IP 位址，而是輸入域名。DNS（Domain Name System）負責將容易記憶的域名映射到對應的 IP 位址。當你在瀏覽器輸入域名時，電腦會向 DNS 伺服器查詢對應的 IP，然後用這個 IP 與伺服器建立連線。

[02:20] Proxy 與 Reverse Proxy

當你造訪網站時，請求不一定直接到達伺服器，有時會先經過 Proxy 或 Reverse Proxy。Proxy（正向代理）作為你的裝置與網路之間的中間人，它會隱藏你的 IP 位址，保護你的身份隱私。Reverse Proxy（反向代理）則相反，它攔截客戶端請求，根據預定義的規則將請求轉發到後端伺服器。

[03:00] Latency 與多資料中心部署

客戶端與伺服器通訊時總會有延遲。物理距離是延遲的最大原因之一。例如伺服器在紐約，但印度的用戶發送請求，資料需要穿越半個地球往返，這種往返延遲稱為 Latency。高延遲會讓應用感覺緩慢。解決方案之一是在全球多個資料中心部署服務，讓用戶連接到最近的伺服器。

[03:45] HTTP 與 HTTPS

客戶端和伺服器使用 HTTP 協議溝通，這就是為什麼大多數 URL 以 HTTP 或 HTTPS 開頭。客戶端發送的請求包含 Header（請求類型、瀏覽器資訊、Cookie 等）和有時包含 Body（如表單輸入）。HTTP 有一個重大安全漏洞——它以明文傳輸資料。HTTPS 透過 SSL/TLS 協議加密所有資料，即使被截獲也無法讀取或篡改。

[04:50] API：REST 與 GraphQL

HTTP 只是資料傳輸協議，並沒有定義請求應如何結構化。API（Application Programming Interface）作為中間層，讓客戶端無需關心底層細節就能與伺服器溝通。

REST 是最廣泛使用的 API 風格。它是無狀態的（每個請求獨立），一切都被視為資源（users、orders、products），使用標準 HTTP 方法（GET、POST、PUT、DELETE）。REST 簡單、可擴展、容易快取，但在複雜資料擷取時可能效率不佳——端點常回傳比需要更多的資料。

GraphQL 由 Facebook 在 2015 年推出，讓客戶端精確指定需要的資料。用 REST 取得用戶資料及其最近貼文可能需要多次請求，GraphQL 可以合併為一次查詢。但 GraphQL 在伺服器端需要更多處理，且不像 REST 那樣容易快取。

[06:50] 資料庫：SQL vs NoSQL

客戶端通常需要儲存或讀取資料。現代應用處理的資料量遠超記憶體所能有效處理的範圍，因此需要專用的資料庫伺服器。

SQL 資料庫以表格形式儲存資料，有嚴格的預定義 Schema，遵循 ACID 特性。適合需要強一致性和結構化關聯的應用，如銀行系統。

NoSQL 資料庫不需要固定 Schema，專為高擴展性和效能設計。資料模型包括 Key-Value Store、Document Store、Graph Database 和 Wide-Column Store。

許多現代應用會同時使用 SQL 和 NoSQL。

[08:30] 垂直擴展 vs 水平擴展

隨著用戶增長，請求量也隨之增加。垂直擴展（Vertical Scaling）是升級現有伺服器的 CPU、RAM 或儲存空間，讓單一機器更強大。但它有明顯限制：每台機器都有硬體上限、高規格伺服器指數級昂貴、單點故障風險。

水平擴展（Horizontal Scaling）則是增加更多伺服器來分擔負載。更多伺服器代表更多容量，系統能更有效地處理增長的流量。如果一台伺服器當機，其他伺服器可以接手，提升可靠性。

[09:50] Load Balancer

水平擴展帶來新挑戰：客戶端怎麼知道該連接哪台伺服器？Load Balancer（負載均衡器）位於客戶端和後端伺服器之間，作為流量管理者，將請求分配到多台伺服器。如果某台伺服器掛了，Load Balancer 會自動將流量重導到其他健康的伺服器。常見的負載均衡演算法包括 Round Robin、Least Connections 和 IP Hashing。

[10:40] 資料庫 Indexing

Indexing（索引）是加速資料庫讀取查詢最快速有效的方式之一。就像書末的索引頁，讓你直接跳到相關章節，而不用翻閱每一頁。索引儲存欄位值和指向實際資料行的指標。索引通常建立在頻繁查詢的欄位上，如 Primary Key、Foreign Key 和常用於 WHERE 條件的欄位。但索引會減慢寫入速度，因為每次資料變更都需要更新索引。

[11:50] 資料庫 Replication

當單一資料庫伺服器無法處理持續增長的讀取請求時，可以使用 Replication（複製）。架構上有一個 Primary（主要副本）負責所有寫入操作，多個 Read Replica（讀取副本）處理讀取查詢。寫入 Primary 的資料會被複製到 Read Replica 保持同步。Replication 改善讀取效能、提升可用性——如果 Primary 故障，Read Replica 可以晉升為新的 Primary。

[12:55] Sharding（分片）

當服務擁有數百萬用戶、資料達到 TB 級別時，單一資料庫伺服器終將不堪負荷。Sharding 將資料庫分割成更小、更易管理的部分（Shard），分佈到多台伺服器上。每個 Shard 包含總資料的子集，資料根據 Sharding Key（如 User ID）進行分配。Sharding 也稱為水平分區（Horizontal Partitioning），按行分割資料。

[13:45] Vertical Partitioning（垂直分區）

如果問題不是行數太多，而是欄位太多呢？Vertical Partitioning 按欄位分割資料庫。例如，一個用戶表格儲存了個人資料、登入記錄和帳單資訊，可以將其拆分為更小、更聚焦的表格。這樣每次查詢只需掃描相關欄位，減少不必要的磁碟 I/O。

[14:30] Caching（快取）

無論怎麼優化資料庫，從磁碟讀取資料總比從記憶體讀取慢。Caching 將頻繁存取的資料存入記憶體。最常見的快取策略是 Cache-Aside 模式：用戶請求資料時，先檢查快取；如果命中就直接回傳；如果未命中，從資料庫讀取後存入快取再回傳。為防止過期資料被回傳，會設定 TTL（Time To Live）。

[15:30] Denormalization（反正規化）

關聯式資料庫使用 Normalization 將資料拆分到不同表格以減少冗餘，但這引入了 JOIN 操作。隨著資料量增長，JOIN 會拖慢查詢。Denormalization 透過將相關資料合併到單一表格來減少 JOIN，即使這意味著某些資料會被重複儲存。適用於讀取密集型應用，但代價是增加儲存空間和更複雜的更新操作。

[16:30] CAP Theorem

當系統擴展到多台伺服器、多個資料庫和資料中心時，就進入了分散式系統的領域。CAP 定理指出，沒有任何分散式系統能同時實現以下三者：Consistency（一致性）、Availability（可用性）、Partition Tolerance（分區容錯性）。由於網路故障是不可避免的，我們必須在 CP（一致性 + 分區容錯）和 AP（可用性 + 分區容錯）之間做出選擇。

[17:15] Blob Storage 與 CDN

現代應用不只處理文字記錄，還需要處理圖片、影片、PDF 等大型檔案。傳統資料庫不適合儲存大型非結構化檔案，因此我們使用 Blob Storage（如 Amazon S3）。Blob 儲存在雲端的容器（Bucket）中，每個檔案有唯一的 URL。

但直接從 Blob Storage 串流影片可能很慢。CDN（Content Delivery Network）是一個全球分散式伺服器網路，根據用戶的地理位置提供內容。內容從最近的 CDN 伺服器提供，用戶體驗到更快的載入時間和最少的緩衝。

[18:50] WebSocket

大多數 Web 應用使用 HTTP 的請求-回應模型。但對於即時聊天、股票行情、線上多人遊戲等即時應用，HTTP 太慢且低效。用 HTTP 實現即時更新只能靠 Polling（頻繁輪詢），但大部分回應是空的，浪費頻寬。

WebSocket 允許客戶端和伺服器之間建立持久的雙向連線。伺服器可以隨時主動推送更新，客戶端也能即時發送訊息，無需輪詢。

[19:50] Webhook

WebSocket 實現的是客戶端與伺服器之間的即時通訊。但如果是伺服器需要通知另一個伺服器呢？例如用戶付款後，支付閘道需要即時通知你的應用。Webhook 讓伺服器在事件發生時，主動發送 HTTP POST 請求到另一個伺服器的指定 URL，而不是不斷輪詢 API 檢查事件是否發生。

[20:30] 微服務架構

傳統應用使用 Monolithic 架構，所有功能在一個大型程式碼庫中。對大型系統來說，Monolith 變得難以管理、擴展和部署。微服務架構將應用拆分為更小的獨立服務，每個 Microservice 負責單一職責、有自己的資料庫和邏輯，可以獨立擴展，透過 API 或 Message Queue 與其他服務溝通。

[21:15] Message Queue

當多個微服務需要溝通時，直接 API 呼叫並不總是高效的。同步通訊（等待即時回應）在大規模下擴展性差。Message Queue 讓服務非同步溝通：Producer 將訊息放入佇列，Queue 暫存訊息，Consumer 取出並處理訊息。這實現了服務解耦，提升擴展性，並防止內部服務過載。

[22:00] Rate Limiting 與 API Gateway

如何防止公開 API 被濫用？Rate Limiting 限制客戶端在特定時間範圍內的請求數量。例如每分鐘 100 次請求，超過限制就暫時封鎖並回傳錯誤。常見的限流演算法有 Fixed Window、Sliding Window 和 Token Bucket。

API Gateway 是一個集中式服務，處理認證、限流、日誌、監控、請求路由等功能。它作為所有客戶端請求的單一入口，將請求路由到適當的微服務。

[23:10] Idempotency（冪等性）

在分散式系統中，網路故障和重試很常見。如果用戶不小心重新整理付款頁面，系統可能收到兩次付款請求。Idempotency（冪等性）確保重複請求產生與單次請求相同的結果。做法是為每個請求分配唯一 ID，處理前先檢查該請求是否已被處理過——如果是，忽略重複請求；如果否，正常處理。

我的想法

這部影片的最大價值在於它提供了一個清晰的系統設計「知識地圖」。對初學者來說，系統設計最令人挫敗的不是單一概念有多難，而是不知道該學什麼、學到什麼程度。這 30 個概念基本上涵蓋了系統設計面試和實際工程中最常見的主題。

值得注意的是，影片從最底層的 Client-Server 開始，一路往上構建到微服務和分散式系統，這個學習順序本身就很有參考價值。每個概念的引入都是因為前一個概念遇到了瓶頸——需要擴展所以引入 Load Balancer，讀取太慢所以引入 Caching，單體架構難以維護所以引入微服務。理解這個「為什麼需要它」的脈絡，比單純記住每個技術是什麼更重要。

不過這部影片畢竟是高層次概覽，每個概念只做了簡要介紹。建議把它當作學習路線圖，針對自己不熟悉的概念再深入研究。特別是 CAP Theorem、Sharding 策略選擇、快取失效策略這些主題，在實際工程中的決策遠比影片中描述的複雜。