系統設計面試：設計Netflix

「設計Netflix」是一個以讀取為主的問題，受一個事實所支配：在全球規模上提供影片服務，更多的是內容傳遞與儲存的問題，而不是運算問題。面試官希望看到你把控制平面（瀏覽、搜尋、推薦）和資料平面（真正傳輸位元組）分開，並推理如何把以PB計的資料交付到離使用者更近的地方。

按部就班地推進：先釐清需求，再估算規模，設計上傳／轉碼流水線，然後設計透過CDN的播放路徑，最後以自適應位元速率與取捨收尾。以下的解析遵循這個結構，讓你練習的是推理過程，而不是死記一套架構。

1. 釐清需求

把功能性需求與非功能性需求分開，並嚴格限定範圍。核心是：使用者瀏覽目錄，並能在不同裝置和網路條件下流暢地觀看影片。

功能性：瀏覽／搜尋目錄、開始播放、自適應畫質、從上次中斷處繼續、多裝置支援。
非功能性：極高的可用性、低啟動延遲、流暢播放（不卡頓）、全球覆蓋。
範圍之外（要明確說出來）：推薦機器學習的內部實作、計費、DRM的細節——提及它們，然後延後處理。

2. 估算規模

這些數字支撐了以CDN為核心的設計。假設有數億訂閱使用者，高峰時有數百萬條並發串流。單條串流就要消耗數Mbps，因此總出口流量可達每秒數十太位元——不可能只靠少數幾個中心資料中心來提供服務，這立刻促成了在邊緣進行快取的設計。

3. 內容接收與轉碼流水線

上傳的母版會離線處理，而不是在播放路徑上處理。每一部作品都會被轉碼成多種清晰度版本——多種解析度和位元速率——並切分成幾秒鐘一段的小片段，以支援自適應串流。

轉碼集群：把母版轉換成多種位元速率下的H.264/H.265/AV1版本；這是一種極易平行化的批次處理工作。
切片與打包：把每個清晰度版本切分成短片段，並生成描述它們的清單檔（HLS/DASH）。
把輸出結果作為唯一可信來源存入物件儲存（類似S3），然後在需求出現之前把熱門內容推送到邊緣。

4. CDN與播放路徑

播放是由邊緣節點而不是源站提供服務的。影片片段會被快取在實體上靠近使用者的CDN節點上（Netflix在ISP內部運營自己的Open Connect裝置）。客戶端先取得清單檔，再從最近的健康邊緣節點拉取片段。

控制平面（目錄、搜尋、使用者檔案、「繼續觀看」）是一組獨立的無狀態API服務，背後有各自的資料庫和快取——它只回傳元資料和清單檔的URL，與繁重的位元組傳輸完全解耦。

邊緣快取（CDN／Open Connect）：承擔絕大部分位元組的傳輸；會在需求出現之前，按地區預先放置熱門內容。
源站儲存：支撐快取未命中情況的物件儲存。
控制平面API：目錄、播放授權、收藏——負載體積小，水平擴展，並配有前置快取。

5. 自適應位元速率串流

在網路條件變化下實現流暢播放，靠的是客戶端而非伺服器。播放器會監測吞吐量和緩衝水位，並借助清單中的清晰度版本列表在片段之間調高或調低畫質——在快速連線上使用更高位元速率，在慢速連線上降低位元速率以避免卡頓。

6. 需要說出來的取捨

最後點出面試官想聽到的那些張力：預先計算所有清晰度版本的儲存成本，與即時轉碼帶來的延遲之間的取捨（Netflix選擇預先計算——儲存比啟動延遲更便宜）；把所有內容都快取，與只在邊緣快取熱門內容之間的取捨（長尾目錄不可能全部放在每個邊緣節點）；以及像「繼續觀看」這類控制平面資料的強一致性與最終一致性之間的取捨（最終一致性就足夠）。明確說出這些取捨，才能讓答案顯得老練。

藉助即時輔助練習Netflix的系統設計

Natively的系統設計面試助手能在實際面試中幫你保持結構清晰——即時建議接下來該涵蓋的面向，並呈現取捨，一切都在你自己的裝置上完成。