Paperdraw：免費的系統設計模擬器，拖拉元件就能看流量、故障、延遲的真實反應

你上次畫系統設計圖，是什麼感覺？

在白板上（或 Excalidraw 裡）畫出 load balancer、幾台 server、一個資料庫、一層 cache——看起來很完整，連線也對了。但你怎麼知道這個設計在真實流量下能不能活？

這就是 system design 困難的地方：靜態圖表告訴不了你動態行為。

什麼是系統設計，為什麼它不只是面試題

System design 的核心問題是：你如何設計一個分散式系統，讓它在真實世界的混亂中還能正確運作？

真實世界的混亂包含：

• 某台 server 突然掛掉
• 資料庫的 replication lag 在流量高峰時拉長到數秒
• cache 同時被大量請求擊穿（cache stampede）
• 一個服務的延遲升高，導致下游服務 timeout，cascade failure 開始蔓延

面試裡問的 system design 題目——「設計一個 Twitter」、「設計一個 URL shortener」——是在測你有沒有思考這些問題的框架。但框架只是起點。真正的挑戰是，你能不能在設計階段就預判系統在壓力下的行為，而不是等到 production 炸了才知道。

這個能力過去只有一種方式習得：在真實系統裡吃夠多的虧。

Paperdraw 做了什麼

Paperdraw 是一個跑在瀏覽器裡的系統設計模擬器。

操作邏輯很直觀：把元件拖進畫布，連線，設定參數，然後讓模擬器跑起來。你可以看到請求在系統裡流動、各節點的負載狀況、哪裡開始出現瓶頸、哪個節點在壓力下先倒下。

關鍵點是：這不是 Lucidchart 或 Excalidraw 那種畫圖工具。畫圖工具讓你呈現架構；Paperdraw 讓你執行架構。

你可以模擬的條件包括：

• Traffic spike：把每秒請求數調高，看 load balancer 的分流策略能不能撐住
• Node failure：把某台 server 設成 down，看 failover 機制有沒有接住
• Latency injection：讓某個依賴服務變慢，觀察超時設定夠不夠細緻
• Scaling events：動態加入新的 server 節點，看 rebalancing 的效果

這些場景在真實系統裡每隔一段時間都會發生。Paperdraw 讓你在設計階段就能思考：我的架構對這些衝擊的反應是什麼？

為什麼模擬比白板有效

白板設計的問題不在白板本身，在於靜態圖天生隱藏了時序問題。

一張架構圖可以同時顯示所有元件和它們的關係，但真實系統是在時間軸上運行的。Cache miss 的那一刻會發生什麼？當 primary database 過載，寫入開始 queue 起來，downstream 的服務有沒有辦法優雅降級？這些問題在靜態圖裡根本看不出來，需要你用大腦在腦中模擬一遍——而大腦的模擬能力是有限的，特別是在處理並發問題時。

幾個常見的設計錯誤，在模擬器裡都會立刻現形：

Thundering herd：大量請求同時打向 cache，在 cache 還沒預熱的狀況下全部穿透到資料庫。你在圖上畫了 cache 層，但你沒有想到這個場景。

Cascading timeout：服務 A 呼叫服務 B，B 呼叫 C。C 開始變慢，B 的 thread pool 被 C 的慢請求佔滿，A 的 timeout 比 B 到 C 的路徑還短。最後 A 看起來正常，但所有通過 B 的請求都開始失敗。

Replication lag 的真實代價：流量高峰時，primary 的寫入速度超過 replica 的複製速度，lag 從毫秒級拉到秒級。如果你的讀取流量全打 replica，使用者開始看到舊資料——這種情況在靜態圖裡完全不可見。

這些問題都不難理解。難的是在設計階段就意識到它們存在。模擬器的價值正在這裡：它把時序問題變得可見。

三個核心使用場景

面試準備

System design 面試的評分重點不是你能不能畫出正確的圖，而是你能不能主動思考設計的邊界和弱點。「這個設計在流量十倍的時候會發生什麼？」、「如果 cache 層整個掛掉，系統會如何降級？」——這些問題，Paperdraw 讓你在面試前就有機會動手驗證，而不只是口頭推理。

學習分散式系統

分散式系統的教材大多是文字和靜態圖，但這個領域的核心概念——consistency vs availability、partition tolerance、backpressure、circuit breaker——在腦袋裡理解和親眼看到行為之間，差距是很大的。Paperdraw 提供了一個低成本的觀察窗口。

架構決策的早期驗證

在開始實作之前，你想對比兩個方案：直接連資料庫，還是在中間加一層 read replica 加上 cache？把兩個架構分別在模擬器裡跑一遍相同的流量場景，行為差異馬上可見。這不能取代 load test，但在設計階段做出更有根據的決策，能省下不少後期的 rework。

工具平民化的意義

五年前，要學好 system design，基本上只有兩條路：

一是進大公司，在真實系統裡被問題砸過幾次。

二是花幾百美金買 Grokking the System Design Interview、System Design Interview 這類課程，然後把那些場景用想像力模擬。

這兩條路對很多人來說都不是真正開放的。

Paperdraw 這類工具改變的不只是學習方式，而是學習這件事的入場門檻。一個在台灣讀資工大三的學生，和一個在 Google 工作五年的工程師，現在都可以用同一個工具驗證同一個架構假設。

不是說工具能替代經驗——它不能。真實系統的複雜度遠超任何模擬器。但它讓「思考分散式系統行為」這件事變得具體、可操作、可重複練習。

它做不到什麼

誠實地說：Paperdraw 是一個學習和設計驗證工具，不是 production 決策的根據。

真實的效能問題來自 kernel 層的 I/O 模型、網路拓撲、資料分佈的 skew、垃圾回收的 pause time——這些細節在任何視覺化模擬器裡都會被抽象化。如果你要驗證一個系統能不能撐過每秒十萬請求，你需要真正的 load test。

同樣，真實分散式系統裡的 Byzantine fault、時鐘不同步、網路分區——這些問題的複雜度比任何模擬器的抽象模型都高得多。

Paperdraw 填的是一個特定的 gap：在設計階段提早思考動態行為，把直覺從靜態圖提升到可以感知時序和壓力的程度。這個 gap 是真實存在的，而且過去沒有什麼好工具填它。

試試看

Paperdraw 免費，不需要帳號，直接用瀏覽器打開就能用。如果你正在準備 system design 面試，或者對分散式系統的行為好奇，花半小時把一個你熟悉的系統架構搭起來跑一遍，是個不錯的起點。

一個合理的練習方式：先畫一個最簡單的版本（一台 server、一個資料庫），然後逐步加入 cache、replica、load balancer，每加一層就注入一次流量衝擊，觀察系統行為的變化。這個過程本身就是在建立對分散式系統的直覺。

靜態圖告訴你架構長什麼樣。模擬器告訴你它在壓力下怎麼死。兩種視角都需要。