前言
面對系統設計（System Design），很多人會卡在第一步：
我知道這些名詞，但不知道該從哪個角度拆。
這篇文章用「五維度分析法」，從底層事實一路走到架構盲點，拆解一個動態網站（以社群媒體的註冊、發文、追蹤為例）到底怎麼運作。
這篇你可以帶走什麼
- 動態網站最核心的 5 個基礎積木
- 這套架構在什麼條件下好用、什麼時候會失效
- 新手最常忽略的兩個效能與協作陷阱
- 下一步學習系統設計的實作路線
維度一、可直接觀察的事實：網站運作的 5 個核心積木
在系統底層，先看不具爭議的客觀事實。動態網站通常由以下 5 個積木組成：
- 基礎互動機制：瀏覽器發送 HTTP 請求（Request），伺服器透過路由（Router）把請求分派到對應函式，最後回傳 HTTP 響應（Response，含狀態碼與內容）。
- 前後端分離原則：為了可維護性，必須把「畫面怎麼呈現（表現邏輯）」與「資料怎麼處理（業務邏輯）」分開。
- 資料庫溝通術：除了手寫 SQL，現代開發常用 ORM（物件關聯對映）把資料操作抽象成程式物件。
- 關聯式資料模型：以 Timeline 為例，至少會有三張表：User、Post、Follows Relation（多對多追蹤關係）。
- API 現代化：後端主流不再直接回傳完整 HTML，而是提供 RESTful API，回傳 JSON，讓 Web 或 App 端自行渲染。
重點：這 5 個積木是「會動起來」的最低條件，不是「可規模化」的保證。
維度二、條件檢查：這套架構何時完美？何時會崩潰？
一般情況下的最佳解
對剛起步的專案來說，
MVC 架構 + ORM + 關聯式資料庫 + RESTful API，通常是兼顧開發速度與穩定性的黃金標準。
邊界條件（什麼時候會失效？）
當使用者從 100 人暴增到 100 萬人，瓶頸會快速浮現。
影片提到以資料庫直接做時間降冪排序來生成時間線；如果一個網紅追蹤 5000 人，而這些人每天都高頻發文，單靠資料庫即時撈資料、排序、分頁，系統很容易超時，甚至當機。
重點：一開始能跑，不代表流量放大後也能撐住。
維度三、反證檢查：新手最容易掉進的兩個坑
跳脫直覺，這套看起來很合理的架構，仍有兩個常見盲點：
-
ORM 的效能陷阱 ORM 讓開發變快，但也容易讓人忽略底層實際產生的 SQL（例如 N+1 查詢）。遇到複雜查詢時，手動寫原生 SQL 往往是效能關鍵。
-
前後端分離的雙面刃 RESTful API 讓後端職責更清楚，但代價是把狀態管理壓力轉移到前端，並增加身分驗證（如 Token）與錯誤處理的複雜度。
維度四、不確定性與假設分析
核心假設：這套架構能順利運作，建立在兩個前提上：
- 資料具備高度結構化特性
- 系統初期處於單機運作狀態
在真實商業環境中，光靠三張基礎資料表與一台伺服器，通常無法撐起大型社交應用。
維度五、最終結論與行動建議
如果你正在學習系統設計，建議先走這條路：
破關路線圖（信心度 95%）
- 先別急著談百萬流量。
- 先把 RESTful API 的開發規範落實，並搞懂資料庫 PK/FK（主鍵/外鍵）概念。
- 先把註冊、發文、追蹤這三個核心流程穩定跑通，這會是最扎實的第一步。
脆弱點提示
如果你未來目標是影音串流、即時連線對戰，或 AI 巨量資料運算，那這篇提到的「傳統 HTTP 請求 + 關聯式資料庫」架構就不太適用，你需要切換到另一套知識體系。
一句話總結
先把基礎積木搭對，再談規模化；先把核心流程跑穩，再談高流量優化。