系統設計面試完整攻略（2026 中文版）

系統設計面試是很多台灣工程師的弱點。不是因為不懂技術，而是因為面試的形式和一般工作不一樣：你要在 45 分鐘內，從一個模糊的問題，設計出一個說得通的大型系統，同時要邊畫邊解釋，還要跟面試官互動。

這份攻略從零開始，帶你搞懂系統設計面試的每一個環節。

系統設計面試的本質

面試官給你的問題通常很模糊，例如：「設計 WhatsApp」。

但他不是真的要你設計 WhatsApp。他想看的是：

你問什麼問題 — 你有沒有先問清楚 scope 和需求？
你怎麼拆問題 — 你有沒有把一個複雜問題分解成可處理的模塊？
你選了什麼技術，為什麼 — 你的判斷有沒有依據？
你知道 tradeoff 是什麼 — 任何技術選擇都有代價，你說得出來嗎？
你能不能在壓力下有條理地溝通 — 這很重要，因為這就是你在工作中做架構討論的樣子。

45 分鐘答題框架

第 1–5 分鐘：釐清需求
第 5–10 分鐘：估算規模（Back-of-the-envelope）
第 10–30 分鐘：High-level 架構設計
第 30–45 分鐘：Deep dive（通常由面試官引導）

第一步：釐清需求（絕對不要跳過）

功能性需求（要做什麼）：

這個系統的核心功能是什麼？
哪些功能在 scope 內，哪些不是？
用戶是誰？使用情境是什麼？

非功能性需求（要做到多好）：

規模：每天多少用戶？每秒多少請求（QPS）？
可用性：允許多少 downtime（99.9% vs 99.99%）？
一致性：強一致性還是最終一致性？
延遲：p99 latency 要求是多少？
資料量：要儲存多少資料？

第二步：規模估算

做個粗略計算，幫助你決定需要什麼等級的架構：

範例：設計 Twitter

DAU（日活用戶）：1 億
每個用戶平均每天發 1 則推文
Write QPS = 100M / 86400 ≈ 1,200 QPS

每個用戶平均每天讀 100 則推文（刷動態）
Read QPS = 100M × 100 / 86400 ≈ 116,000 QPS

→ 讀寫比 ≈ 100:1，這是一個「讀多寫少」的系統
→ 需要重度快取策略

第三步：High-level 架構

畫出主要元件（不要畫太細）：

客戶端（Client）
Load Balancer
Web Servers / API Servers
資料庫
快取層（Cache）
訊息佇列（Message Queue）
CDN（如果需要）

說明資料流：「用戶發請求 → 到 Load Balancer → 到 API Server → 查 Cache，miss 了才查 DB → 回傳」

第四步：Deep dive

面試官通常會在這裡問：「那你的資料庫設計是怎樣？」或「如果有 10 億用戶怎麼辦？」

你要能夠對你設計中的每個元件問三層深。準備以下幾個常見的 deep dive 方向：

資料庫 schema 設計
Sharding / Partitioning 策略
快取失效（Cache invalidation）
高可用（HA）和 failover
讀寫分離

必備基礎知識

1. CAP 定理

分散式系統只能保證三個特性中的兩個：

C（Consistency）：所有節點看到的資料是一致的
A（Availability）：每個請求都會得到回應
P（Partition tolerance）：節點間的網路中斷時系統仍可運作

因為網路分割（P）在實際系統中是必然會發生的，所以你通常是在 CP 和 AP 之間選擇。

CP 例子：銀行轉帳（寧可不回應，也不能回傳錯的餘額）
AP 例子：社交媒體動態（可以短暫不一致，但不能停服務）

2. 資料庫選型

| 選 SQL | 選 NoSQL | |---|---| | 需要 ACID 交易 | 需要水平擴展（Horizontal scaling） | | 資料結構明確 | Schema 變動頻繁 | | 關聯查詢複雜 | 需要極低延遲 | | 例：交易、訂單 | 例：用戶 session、推薦快取 |

常見 NoSQL 類型：

Key-Value：Redis、DynamoDB — 適合快取、session
Document：MongoDB、Firestore — 適合彈性 schema
Column-family：Cassandra、HBase — 適合寫入密集、時序資料
Graph：Neo4j — 適合社交關係、推薦圖

3. 快取策略

Cache-aside（最常用）：先查快取，miss 了再查 DB，然後寫回快取。

Write-through：寫入時同時更新快取和 DB，一致性高但寫入較慢。

Write-behind（Write-back）：先寫快取，異步寫入 DB，寫入快但有資料丟失風險。

快取失效策略：TTL 過期、LRU 淘汰、事件驅動的主動失效。

4. 訊息佇列

為什麼要用 MQ（Message Queue）：

解耦（Decoupling）：發布者和訂閱者不需要同時在線
削峰（Traffic shaping）：突發流量緩衝
異步處理：不需要等待的工作放 queue

Kafka vs RabbitMQ vs SQS：

Kafka：高吞吐、持久化、replay 能力強，適合 event streaming
RabbitMQ：更靈活的路由，適合 task queue
SQS：AWS 托管，簡單好用，適合雲端原生架構

5. 一致性 Hash

用在分散式快取和資料庫 sharding。優點：新增或移除節點時，只需要重新分配少量資料（而不是重新 hash 所有資料）。

10 道經典題解析

1. URL Shortener（bit.ly）

核心需求：

輸入長 URL，輸出短碼（6 位英數字）
短碼可以重定向到原始 URL
QPS：100 write / 10,000 read（讀多寫少）

關鍵設計決策：

ID 生成方案：

Hash（MD5/SHA256）取前 6 位 — 簡單，有碰撞風險
全域自增 ID + Base62 編碼 — 不碰撞，需要全域序號服務
雪花算法（Snowflake ID）— 分散式友好，無碰撞

資料庫：

Key-Value store（Redis + 持久化 DB）
URLs table：id | short_code | original_url | created_at | expires_at

快取策略：

用 Redis 快取熱門短碼
TTL = 1 天，熱門的可以 pin 住

Deep dive 方向：同一個 URL 要不要給同一個短碼？（需求取向，通常不需要）

2. Twitter 動態 Feed（Fan-out 問題）

核心設計挑戰：用戶 A 發推文，他的 1 萬個粉絲應該如何看到這則推文？

兩種方案：

Fan-out on write（寫入時展開）：

用戶發推文時，立刻寫進所有粉絲的 timeline cache
優點：讀取快（O(1) 讀快取）
缺點：大 V（百萬粉絲）發文時，寫入 fanout 太重

Fan-out on read（讀取時展開）：

用戶開 app 時，即時 merge 所有關注者的最新推文
優點：大 V 友好
缺點：讀取慢、計算量大

2026 答案：Hybrid

普通用戶：fan-out on write
大 V（粉絲 > 100 萬）：fan-out on read
Twitter 真實做法也是 hybrid

3. WhatsApp 聊天系統

核心需求：

1 對 1 即時訊息
訊息狀態（已傳送、已讀）
離線訊息暫存
連線狀態（online/offline）

架構重點：

協議：

WebSocket（長連接）for real-time messaging
HTTP for 非即時操作（上傳圖片、取歷史訊息）

訊息存儲：

HBase 或 Cassandra（寫入密集、時序查詢）
資料模型：(sender_id, receiver_id, message_id) → message_content

訊息狀態：

送出（delivered to server）→ 已到達（delivered to device）→ 已讀
用 ACK 機制確認，client 收到訊息後回送 ACK

離線訊息：

訊息先存 server，對方上線後推送

4. Rate Limiter（限流器）

最常考的限流算法：

Token Bucket（令牌桶）：

桶裡有固定數量的 token，固定速率補充
請求來了消耗 token，桶空了就拒絕
允許突發流量

Leaky Bucket（漏桶）：

請求進來加到 queue，固定速率處理
超出 queue 容量的請求丟棄
輸出穩定，不允許突發

Sliding Window Counter（滑動窗口計數）：

維持過去 N 秒的精確請求計數
精確但記憶體開銷較大

分散式 Rate Limiter：

Redis 做計數器（INCR + EXPIRE）
Lua script 保證原子操作

5. 通知系統

多管道（Push / Email / SMS）設計：

Producer services → Kafka
  → Router（根據通知類型 fan-out）
    → Push worker → APNs / FCM
    → Email worker → SendGrid / SES
    → SMS worker → Twilio
  → 去重快取（Redis，TTL 對齊 retry 窗口）
  → Retry queue + DLQ（Dead Letter Queue）

重要細節：

冪等性：同一個 event 不能發兩次通知（用 event_id + channel 做 dedup key）
重試策略：指數退避 + 抖動（jitter），最多 5 次
優先級：緊急通知走 fast lane，行銷通知走 slow lane

6. Google Drive（雲端儲存）

文件上傳設計：

大文件分塊上傳（Chunking）
每個 chunk 計算 hash，已上傳的 chunk 不重複上傳（dedup）
斷點續傳

元數據 vs 實際文件分開存：

元數據（文件名、大小、owner、chunk list）→ 關聯式 DB
實際文件內容 → Object Storage（S3 / GCS）

同步衝突解決：

版本向量（Version Vector）
Last-write-wins（簡單但不完美）
顯示衝突讓用戶手動合併（Google Docs 做法）

7. Uber 叫車配對

核心問題：如何在低延遲下找到附近的司機？

地理空間索引方案：

| 方案 | 說明 | 適用場景 | |---|---|---| | Geohash | 把地球格子化，每個格子有字串 key | 簡單、常用 | | S2 Cells（Google） | 球面分割，邊緣更精確 | 高精度需求 | | H3（Uber） | 六邊形格子，均勻覆蓋 | Uber 實際用的 | | Quadtree | 動態空間分割 | 密度不均的場景 |

司機位置更新：

司機每 4 秒發一次 GPS 位置
寫入 Redis Geo（GEOADD）
配對查詢：GEORADIUSBYMEMBER

配對邏輯：

附近 1km 內的空閒司機按 ETA 排序
推送給評分最高的前 N 位，誰先接就誰上

8. 搜尋引擎（簡化版）

核心元件：

倒排索引（Inverted Index）：

詞 → [文件 ID, 位置, 頻率] 的 mapping
這是所有搜尋引擎的核心資料結構

排名（Ranking）：

TF-IDF：詞在文件中的頻率 vs 在所有文件中的稀有度
PageRank：被引用的次數（對網頁搜尋）
現代：BERT 向量相似度 + Learning-to-Rank 模型

Sharding：

按文件 ID hash 分片（document partitioning）
或按詞分片（term partitioning）

9. 支付系統

最重要的概念：冪等性（Idempotency）

用戶點了兩次「付款」，你不能扣兩次錢。

解法：

每次付款請求帶唯一的 idempotency_key（client 生成的 UUID）
Server 端用這個 key 做 dedup，同一個 key 的第二次請求直接回傳第一次的結果

分散式交易（Distributed Transaction）：

本地交易用 SQL ACID 就夠了。跨服務的交易需要：

2PC（Two-Phase Commit）：強一致性，但效能差、有阻塞風險
Saga Pattern：把大交易分解成一系列本地交易，每步都有補償操作（rollback transaction）

10. 即時視頻串流（YouTube/Netflix）

上傳流程：

Raw video → 上傳到 Object Storage → 觸發轉碼 job
轉碼：1080p、720p、480p、360p 多個版本（並行）
縮圖生成、字幕提取

播放流程：

自適應串流（Adaptive Bitrate Streaming）：用 HLS 或 DASH，根據網路速度自動切換畫質
CDN 加速：影片內容分發到全球邊緣節點，降低延遲

評論、按讚分開存：

影片元數據：Relational DB
按讚數：Redis counter（INCR）
評論：Cassandra（寫入密集）
觀看記錄：Kafka → 資料湖

常見問題 FAQ

系統設計面試從幾年資歷開始考？

外商（Google、Meta、Amazon、Shopee）從 L4（3–5 年資歷）就開始有系統設計輪。台灣本地公司通常要 senior（5 年以上）才考。建議從 2–3 年資歷就開始學，因為這需要時間培養。

我可以說「用 Kafka」嗎？還是要自己實作？

面試中說「用 Kafka」完全沒問題，因為工作中也是用現成技術。但你要能解釋為什麼選 Kafka（而不是 RabbitMQ、SQS），以及 Kafka 的基本運作原理（partition、consumer group、offset）。

系統設計面試可以畫圖嗎？

一定要畫！外商面試通常用 Excalidraw、miro、或 Google Jamboard 讓你畫。台灣的實體面試有時候有白板。畫圖是系統設計面試的標配，不畫圖就是在讓面試官猜你的意思。

要先把整個系統設計完，還是可以做到一半再問問題？

可以（也應該）邊設計邊問問題。系統設計是互動式的，不是獨白。面試官通常會引導你往他想深入的方向走。你的工作是提出方向和判斷，他的工作是告訴你要 zoom in 在哪裡。

有沒有推薦的學習資源？

System Design Primer（GitHub，免費）：最好的入門資料
Designing Data-Intensive Applications (DDIA)：進階必讀，重點看第 1–9 章
ByteByteGo（Alex Xu）：視覺化系統設計，適合視覺學習者
HiredPathway：AI 語音模擬系統設計面試，可以練習邊說邊畫的感覺

AI 圖片生成 Prompts

Hero 圖

Midjourney：

Wide editorial photograph of a software engineer drawing a system architecture diagram on a whiteboard, boxes and arrows showing server infrastructure, warm office lighting, focused concentration, whiteboard markers in multiple colors, modern tech office aesthetic --ar 16:9 --v 6 --style raw

架構圖示意圖

Ideogram：

Clean minimal system architecture diagram showing Client → Load Balancer → API Servers → Cache → Database, with labeled arrows and Chinese annotation underneath each component, light grey background, navy and coral color scheme, textbook technical diagram style --ar 16:9

系統設計面試完整攻略（2026 中文版）

這份攻略從零開始，帶你搞懂系統設計面試的每一個環節。

系統設計面試的本質

面試官給你的問題通常很模糊，例如：「設計 WhatsApp」。

但他不是真的要你設計 WhatsApp。他想看的是：

你問什麼問題 — 你有沒有先問清楚 scope 和需求？
你怎麼拆問題 — 你有沒有把一個複雜問題分解成可處理的模塊？
你選了什麼技術，為什麼 — 你的判斷有沒有依據？
你知道 tradeoff 是什麼 — 任何技術選擇都有代價，你說得出來嗎？
你能不能在壓力下有條理地溝通 — 這很重要，因為這就是你在工作中做架構討論的樣子。

45 分鐘答題框架

第 1–5 分鐘：釐清需求
第 5–10 分鐘：估算規模（Back-of-the-envelope）
第 10–30 分鐘：High-level 架構設計
第 30–45 分鐘：Deep dive（通常由面試官引導）

第一步：釐清需求（絕對不要跳過）

功能性需求（要做什麼）：

這個系統的核心功能是什麼？
哪些功能在 scope 內，哪些不是？
用戶是誰？使用情境是什麼？

非功能性需求（要做到多好）：

規模：每天多少用戶？每秒多少請求（QPS）？
可用性：允許多少 downtime（99.9% vs 99.99%）？
一致性：強一致性還是最終一致性？
延遲：p99 latency 要求是多少？
資料量：要儲存多少資料？

第二步：規模估算

做個粗略計算，幫助你決定需要什麼等級的架構：

範例：設計 Twitter

DAU（日活用戶）：1 億
每個用戶平均每天發 1 則推文
Write QPS = 100M / 86400 ≈ 1,200 QPS

每個用戶平均每天讀 100 則推文（刷動態）
Read QPS = 100M × 100 / 86400 ≈ 116,000 QPS

→ 讀寫比 ≈ 100:1，這是一個「讀多寫少」的系統
→ 需要重度快取策略

第三步：High-level 架構

畫出主要元件（不要畫太細）：

客戶端（Client）
Load Balancer
Web Servers / API Servers
資料庫
快取層（Cache）
訊息佇列（Message Queue）
CDN（如果需要）

說明資料流：「用戶發請求 → 到 Load Balancer → 到 API Server → 查 Cache，miss 了才查 DB → 回傳」

第四步：Deep dive

面試官通常會在這裡問：「那你的資料庫設計是怎樣？」或「如果有 10 億用戶怎麼辦？」

你要能夠對你設計中的每個元件問三層深。準備以下幾個常見的 deep dive 方向：

資料庫 schema 設計
Sharding / Partitioning 策略
快取失效（Cache invalidation）
高可用（HA）和 failover
讀寫分離

必備基礎知識

1. CAP 定理

分散式系統只能保證三個特性中的兩個：

C（Consistency）：所有節點看到的資料是一致的
A（Availability）：每個請求都會得到回應
P（Partition tolerance）：節點間的網路中斷時系統仍可運作

因為網路分割（P）在實際系統中是必然會發生的，所以你通常是在 CP 和 AP 之間選擇。

CP 例子：銀行轉帳（寧可不回應，也不能回傳錯的餘額）
AP 例子：社交媒體動態（可以短暫不一致，但不能停服務）

2. 資料庫選型

常見 NoSQL 類型：

Key-Value：Redis、DynamoDB — 適合快取、session
Document：MongoDB、Firestore — 適合彈性 schema
Column-family：Cassandra、HBase — 適合寫入密集、時序資料
Graph：Neo4j — 適合社交關係、推薦圖

3. 快取策略

Cache-aside（最常用）：先查快取，miss 了再查 DB，然後寫回快取。

Write-through：寫入時同時更新快取和 DB，一致性高但寫入較慢。

Write-behind（Write-back）：先寫快取，異步寫入 DB，寫入快但有資料丟失風險。

快取失效策略：TTL 過期、LRU 淘汰、事件驅動的主動失效。

4. 訊息佇列

為什麼要用 MQ（Message Queue）：

解耦（Decoupling）：發布者和訂閱者不需要同時在線
削峰（Traffic shaping）：突發流量緩衝
異步處理：不需要等待的工作放 queue

Kafka vs RabbitMQ vs SQS：

Kafka：高吞吐、持久化、replay 能力強，適合 event streaming
RabbitMQ：更靈活的路由，適合 task queue
SQS：AWS 托管，簡單好用，適合雲端原生架構

5. 一致性 Hash

用在分散式快取和資料庫 sharding。優點：新增或移除節點時，只需要重新分配少量資料（而不是重新 hash 所有資料）。

10 道經典題解析

1. URL Shortener（bit.ly）

核心需求：

輸入長 URL，輸出短碼（6 位英數字）
短碼可以重定向到原始 URL
QPS：100 write / 10,000 read（讀多寫少）

關鍵設計決策：

ID 生成方案：

Hash（MD5/SHA256）取前 6 位 — 簡單，有碰撞風險
全域自增 ID + Base62 編碼 — 不碰撞，需要全域序號服務
雪花算法（Snowflake ID）— 分散式友好，無碰撞

資料庫：

Key-Value store（Redis + 持久化 DB）
URLs table：id | short_code | original_url | created_at | expires_at

快取策略：

用 Redis 快取熱門短碼
TTL = 1 天，熱門的可以 pin 住

Deep dive 方向：同一個 URL 要不要給同一個短碼？（需求取向，通常不需要）

2. Twitter 動態 Feed（Fan-out 問題）

核心設計挑戰：用戶 A 發推文，他的 1 萬個粉絲應該如何看到這則推文？

兩種方案：

Fan-out on write（寫入時展開）：

用戶發推文時，立刻寫進所有粉絲的 timeline cache
優點：讀取快（O(1) 讀快取）
缺點：大 V（百萬粉絲）發文時，寫入 fanout 太重

Fan-out on read（讀取時展開）：

用戶開 app 時，即時 merge 所有關注者的最新推文
優點：大 V 友好
缺點：讀取慢、計算量大

2026 答案：Hybrid

普通用戶：fan-out on write
大 V（粉絲 > 100 萬）：fan-out on read
Twitter 真實做法也是 hybrid

3. WhatsApp 聊天系統

核心需求：

1 對 1 即時訊息
訊息狀態（已傳送、已讀）
離線訊息暫存
連線狀態（online/offline）

架構重點：

協議：

WebSocket（長連接）for real-time messaging
HTTP for 非即時操作（上傳圖片、取歷史訊息）

訊息存儲：

HBase 或 Cassandra（寫入密集、時序查詢）
資料模型：(sender_id, receiver_id, message_id) → message_content

訊息狀態：

送出（delivered to server）→ 已到達（delivered to device）→ 已讀
用 ACK 機制確認，client 收到訊息後回送 ACK

離線訊息：

訊息先存 server，對方上線後推送

4. Rate Limiter（限流器）

最常考的限流算法：

Token Bucket（令牌桶）：

桶裡有固定數量的 token，固定速率補充
請求來了消耗 token，桶空了就拒絕
允許突發流量

Leaky Bucket（漏桶）：

請求進來加到 queue，固定速率處理
超出 queue 容量的請求丟棄
輸出穩定，不允許突發

Sliding Window Counter（滑動窗口計數）：

維持過去 N 秒的精確請求計數
精確但記憶體開銷較大

分散式 Rate Limiter：

Redis 做計數器（INCR + EXPIRE）
Lua script 保證原子操作

5. 通知系統

多管道（Push / Email / SMS）設計：

Producer services → Kafka
  → Router（根據通知類型 fan-out）
    → Push worker → APNs / FCM
    → Email worker → SendGrid / SES
    → SMS worker → Twilio
  → 去重快取（Redis，TTL 對齊 retry 窗口）
  → Retry queue + DLQ（Dead Letter Queue）

重要細節：

冪等性：同一個 event 不能發兩次通知（用 event_id + channel 做 dedup key）
重試策略：指數退避 + 抖動（jitter），最多 5 次
優先級：緊急通知走 fast lane，行銷通知走 slow lane

6. Google Drive（雲端儲存）

文件上傳設計：

大文件分塊上傳（Chunking）
每個 chunk 計算 hash，已上傳的 chunk 不重複上傳（dedup）
斷點續傳

元數據 vs 實際文件分開存：

元數據（文件名、大小、owner、chunk list）→ 關聯式 DB
實際文件內容 → Object Storage（S3 / GCS）

同步衝突解決：

版本向量（Version Vector）
Last-write-wins（簡單但不完美）
顯示衝突讓用戶手動合併（Google Docs 做法）

7. Uber 叫車配對

核心問題：如何在低延遲下找到附近的司機？

地理空間索引方案：

司機位置更新：

司機每 4 秒發一次 GPS 位置
寫入 Redis Geo（GEOADD）
配對查詢：GEORADIUSBYMEMBER

配對邏輯：

附近 1km 內的空閒司機按 ETA 排序
推送給評分最高的前 N 位，誰先接就誰上

8. 搜尋引擎（簡化版）

核心元件：

倒排索引（Inverted Index）：

詞 → [文件 ID, 位置, 頻率] 的 mapping
這是所有搜尋引擎的核心資料結構

排名（Ranking）：

TF-IDF：詞在文件中的頻率 vs 在所有文件中的稀有度
PageRank：被引用的次數（對網頁搜尋）
現代：BERT 向量相似度 + Learning-to-Rank 模型

Sharding：

按文件 ID hash 分片（document partitioning）
或按詞分片（term partitioning）

9. 支付系統

最重要的概念：冪等性（Idempotency）

用戶點了兩次「付款」，你不能扣兩次錢。

解法：

每次付款請求帶唯一的 idempotency_key（client 生成的 UUID）
Server 端用這個 key 做 dedup，同一個 key 的第二次請求直接回傳第一次的結果

分散式交易（Distributed Transaction）：

本地交易用 SQL ACID 就夠了。跨服務的交易需要：

2PC（Two-Phase Commit）：強一致性，但效能差、有阻塞風險
Saga Pattern：把大交易分解成一系列本地交易，每步都有補償操作（rollback transaction）

10. 即時視頻串流（YouTube/Netflix）

上傳流程：

Raw video → 上傳到 Object Storage → 觸發轉碼 job
轉碼：1080p、720p、480p、360p 多個版本（並行）
縮圖生成、字幕提取

播放流程：

自適應串流（Adaptive Bitrate Streaming）：用 HLS 或 DASH，根據網路速度自動切換畫質
CDN 加速：影片內容分發到全球邊緣節點，降低延遲

評論、按讚分開存：

影片元數據：Relational DB
按讚數：Redis counter（INCR）
評論：Cassandra（寫入密集）
觀看記錄：Kafka → 資料湖

常見問題 FAQ

系統設計面試從幾年資歷開始考？

我可以說「用 Kafka」嗎？還是要自己實作？

系統設計面試可以畫圖嗎？

要先把整個系統設計完，還是可以做到一半再問問題？

有沒有推薦的學習資源？

System Design Primer（GitHub，免費）：最好的入門資料
Designing Data-Intensive Applications (DDIA)：進階必讀，重點看第 1–9 章
ByteByteGo（Alex Xu）：視覺化系統設計，適合視覺學習者
HiredPathway：AI 語音模擬系統設計面試，可以練習邊說邊畫的感覺

AI 圖片生成 Prompts

Hero 圖

Midjourney：

Wide editorial photograph of a software engineer drawing a system architecture diagram on a whiteboard, boxes and arrows showing server infrastructure, warm office lighting, focused concentration, whiteboard markers in multiple colors, modern tech office aesthetic --ar 16:9 --v 6 --style raw

架構圖示意圖

Ideogram：

Clean minimal system architecture diagram showing Client → Load Balancer → API Servers → Cache → Database, with labeled arrows and Chinese annotation underneath each component, light grey background, navy and coral color scheme, textbook technical diagram style --ar 16:9

系統設計面試完整攻略（2026 中文版）

系統設計面試的本質

45 分鐘答題框架

第一步：釐清需求（絕對不要跳過）

第二步：規模估算

第三步：High-level 架構

第四步：Deep dive

必備基礎知識

1. CAP 定理

2. 資料庫選型

3. 快取策略

4. 訊息佇列

5. 一致性 Hash

10 道經典題解析

1. URL Shortener（bit.ly）

2. Twitter 動態 Feed（Fan-out 問題）

3. WhatsApp 聊天系統

4. Rate Limiter（限流器）

5. 通知系統

6. Google Drive（雲端儲存）

7. Uber 叫車配對

8. 搜尋引擎（簡化版）

9. 支付系統

10. 即時視頻串流（YouTube/Netflix）

常見問題 FAQ

系統設計面試從幾年資歷開始考？

我可以說「用 Kafka」嗎？還是要自己實作？

系統設計面試可以畫圖嗎？

要先把整個系統設計完，還是可以做到一半再問問題？

有沒有推薦的學習資源？

相關文章

AI 圖片生成 Prompts

Hero 圖

架構圖示意圖

系統設計面試完整攻略（2026 中文版）

系統設計面試的本質

45 分鐘答題框架

第一步：釐清需求（絕對不要跳過）

第二步：規模估算

第三步：High-level 架構

第四步：Deep dive

必備基礎知識

1. CAP 定理

2. 資料庫選型

3. 快取策略

4. 訊息佇列

5. 一致性 Hash

10 道經典題解析

1. URL Shortener（bit.ly）

2. Twitter 動態 Feed（Fan-out 問題）

3. WhatsApp 聊天系統

4. Rate Limiter（限流器）

5. 通知系統

6. Google Drive（雲端儲存）

7. Uber 叫車配對

8. 搜尋引擎（簡化版）

9. 支付系統

10. 即時視頻串流（YouTube/Netflix）

常見問題 FAQ

系統設計面試從幾年資歷開始考？

我可以說「用 Kafka」嗎？還是要自己實作？

系統設計面試可以畫圖嗎？

要先把整個系統設計完，還是可以做到一半再問問題？

有沒有推薦的學習資源？

相關文章

AI 圖片生成 Prompts

Hero 圖

架構圖示意圖