[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-system-design-learning-path-from-scratch-zh":3,"article-related-system-design-learning-path-from-scratch-zh":30,"series-tools-05e9b65e-4f55-439e-8bd2-f978dc784b6d":75},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"05e9b65e-4f55-439e-8bd2-f978dc784b6d","system-design-learning-path-from-scratch-zh","System design 一次學會的路線","\u003Cp data-speakable=\"summary\">Azeem 的 system design 路線，把亂掉的練習順序整理成一套能直接照抄的學習法。\u003C\u002Fp>\u003Cp>我以前也很討厭 system design。不是因為我不會寫後端，我 CRUD、auth、cache 都碰過，服務也救過幾次；是因為一碰到開放題，我腦袋就空白。你叫我設計 YouTube，我會先講一堆「應該可以用資料庫」這種廢話，講完自己都知道是在撐場面。最煩的是，這東西看起來像面試表演，像在逼你把一堆名詞排成漂亮圖，但我根本不知道自己到底缺的是什麼。\u003C\u002Fp>\u003Cp>後來我看到這篇 \u003Ca href=\"https:\u002F\u002Fcloudwithazeem.medium.com\u002Fhow-to-learn-system-design-from-scratch-05ee48cda5b2\">How I Finally Learned System Design (After Feeling Totally Lost)\u003C\u002Fa>，才有點醒過來。它不是在賣神技，也不是叫你背一堆架構名詞。它講的是：你要先有一條學習路線，不然你只是在白板前面裝忙。Azeem 這篇原文沒有提供觀看數或書籤數，所以我不亂報數字；但它提供的不是流量，是一個很實際的拆題順序。\u003Ca href=\"https:\u002F\u002Fmedium.com\u002F\">Medium\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fcloudwithazeem.medium.com\u002F\">Cloud With Azeem\u003C\u002Fa>、還有他文中提到的\u003Ca href=\"\u002Fnews\u002Fandroid-june-2026-google-system-updates-zh\">系統\u003C\u002Fa>設計習慣，才是我覺得值得拆的地方。\u003C\u002Fp>\u003Ch2>別把 system design 當面試戲碼\u003C\u002Fh2>\u003Cblockquote>You’ve been building “To-Do” apps and CRUD APIs for three years, and you think you’re a “Senior Engineer.” Then, someone asks you, “How would you design YouTube?” and suddenly you’re sweating through your Patagonia vest.\u003C\u002Fblockquote>\u003Cp>這句話很毒，但我覺得很準。翻譯一下就是：你平常做的是功能題，一旦題目變成系統題，你就會發現自己其實沒學會怎麼想。以前我以為問題是我不懂\u003Ca href=\"\u002Ftag\u002F分散式系統\">分散式系統\u003C\u002Fa>的術語，後來才知道不是。我是一直用「寫功能」的腦袋在想「\u003Ca href=\"\u002Fnews\u002Fastryx-open-source-meta-design-system-zh\">設計系統\u003C\u002Fa>」的題目，當然會卡。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782849806074-jwd5.png\" alt=\"System design 一次學會的路線\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>system design 真正考的不是你會不會講 cache、queue、load balancer，而是你能不能先把問題拆成需求、約束、瓶頸，再慢慢往下收斂。你如果一開始就衝去畫架構圖，那通常只是把焦慮畫成方塊而已。\u003C\u002Fp>\u003Cp>我自己最常犯的錯，是題目一出來就想選技術，像是先決定要不要 Kafka、要不要 microservices、要不要 Redis。這種順序很蠢，因為你還沒搞清楚流量型態、延遲要求、資料一致性，選技術只是自我安慰。\u003C\u002Fp>\u003Cp>實操寫法很簡單：每次練題先逼自己回答三件事。\u003C\u002Fp>\u003Cul>\u003Cli>這個產品的核心動作是什麼？\u003C\u002Fli>\u003Cli>最重要的非功能需求是什麼？\u003C\u002Fli>\u003Cli>最先炸掉的地方會是哪裡？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>你先把這三件事講清楚，再談架構，答案就會正常很多。這不是技巧，這是順序問題。\u003C\u002Fp>\u003Ch2>先學名詞，但不要把名詞當答案\u003C\u002Fh2>\u003Cp>很多人卡住，是因為一開始就跑去背詞典：load balancer、cache、queue、shard、CDN。這些字都要懂，沒錯，但懂名字不等於懂用途。你如果只會背定義，最後就會變成那種面試講得很順、追問一來就露餡的人。\u003C\u002Fp>\u003Cp>Azeem 的路線比較像是先把工具放進情境裡。cache 不是因為它酷，是因為它能減少重複讀取；queue 不是因為它高級，是因為它能把尖峰流量先接住；CDN 不是裝飾，是把靜態內容拉近使用者。也就是說，每個元件都應該對應一個問題，不是對應一個面試關鍵字。\u003C\u002Fp>\u003Cp>我以前最愛亂用 queue。只要系統慢，我就想「丟 queue 啊」。後來才發現，queue 不是萬靈丹。你如果是熱點資料、讀多寫少、或是索引設計有問題，queue 根本不會救你。它只是把問題延後，不是把問題消掉。\u003C\u002Fp>\u003Cp>我現在會這樣練：每學一個元件，就寫下三行。\u003C\u002Fp>\u003Cul>\u003Cli>它解決什麼問題？\u003C\u002Fli>\u003Cli>它會帶來什麼成本？\u003C\u002Fli>\u003Cli>什麼情況下它反而害你？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>例如 cache 會降低延遲，但會有過期資料；queue 能吸收尖峰，但會增加延遲和重試處理；load balancer 能分散流量，但也多了一層路由和監控負擔。你只要一直逼自己回答這三個問題，名詞就不會只是名詞。\u003C\u002Fp>\u003Ch2>先定需求，再決定你要畫什麼架構\u003C\u002Fh2>\u003Cp>我以前很愛先畫「看起來很成熟」的架構。微服務先上、Kafka 先上、服務切一切，感覺很像 senior。後來才知道，這種做法很像先買裝潢再找房子。你還沒弄清楚產品要什麼，就先把系統弄得很複雜，最後只是把維護成本提前買單。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782849804250-rk2w.png\" alt=\"System design 一次學會的路線\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>比較正常的順序，是先把需求收乾淨。這個系統是偏讀還是偏寫？使用者是全球分布還是單區域？資料一致性是硬需求還是可以延遲？即時性到底要到秒級、毫秒級，還是幾分鐘都行？這些問題的答案，會直接決定你該不該用快取、該不該分區、該不該做非同步處理。\u003C\u002Fp>\u003Cp>我很喜歡 Azeem 這篇的地方，就是它沒有把 system design 說成神秘儀式。它其實是在教你怎麼收斂問題。你如果不先定義問題，每個架構看起來都差不多合理；你一旦把限制條件講清楚，很多選項會自己消失。\u003C\u002Fp>\u003Cp>實操時，我建議固定用同一個流程，不要每次 freestyle。\u003C\u002Fp>\u003Col>\u003Cli>先問清楚需求。\u003C\u002Fli>\u003Cli>做粗略流量估算。\u003C\u002Fli>\u003Cli>找出核心資料模型和 API。\u003C\u002Fli>\u003Cli>畫出主要資料流。\u003C\u002Fli>\u003Cli>找瓶頸。\u003C\u002Fli>\u003Cli>最後才加 cache、async、partition。\u003C\u002Fli>\u003C\u002Fol>\u003Cp>這個順序看起來笨，但很有效。因為它逼你先思考問題，再思考解法。\u003C\u002Fp>\u003Ch2>估算不是考數學，是防止你自己亂講\u003C\u002Fh2>\u003Cp>很多人討厭 capacity estimation，因為他們以為那是在比誰算得準。其實不是。它只是讓你不要胡說八道。你如果假設流量很小，設計就會看起來很漂亮；但只要題目一補上規模，整個架構就會像紙糊的一樣。\u003C\u002Fp>\u003Cp>估算的作用，是幫你看見壓力會落在哪裡。是資料庫先爆？還是頻寬先爆？是單台服務撐不住？還是 storage 成本先炸？這些問題不需要精準到小數點，你只需要大概合理。system design 裡面，可信的量級比精準的數字重要太多。\u003C\u002Fp>\u003Cp>我以前會跳過這一步，因為我覺得麻煩。結果就是我畫出來的東西很順眼，直到有人問我「每秒多少 request？」我才發現整個設計根本沒算過。那種尷尬我不想再來一次。\u003C\u002Fp>\u003Cp>實操寫法是準備幾個固定錨點，然後用粗算就好。\u003C\u002Fp>\u003Cul>\u003Cli>日活使用者數\u003C\u002Fli>\u003Cli>每人每天請求數\u003C\u002Fli>\u003Cli>平均 payload 大小\u003C\u002Fli>\u003Cli>尖峰倍數\u003C\u002Fli>\u003C\u002Ful>\u003Cp>再把這些轉成 QPS、儲存量、頻寬和記憶體壓力。你不用算得像財務報表，你只要知道壓力會往哪邊跑。只要你能說出「這裡會熱」、「這裡會慢」、「這裡會貴」，你的答案就比一堆空話有用。\u003C\u002Fp>\u003Ch2>真正的答案通常是取捨，不是標準配方\u003C\u002Fh2>\u003Cp>這是我最想吐槽的一點：很多人以為好的 system design 有標準答案。沒有。大部分時候，你其實是在選代價。多一層 cache，延遲會降，但一致性麻煩；多做副本，可靠性會上去，但同步成本變高；切成 microservices，邊界可能更清楚，但部署、監控、除錯都更煩。\u003C\u002Fp>\u003Cp>所以當面試官問你「為什麼這樣設計」時，真正要講的不是你用了哪些元件，而是你為什麼接受這些代價。Azeem 的文章雖然不是在列一張工具清單，但它很明顯在推你往這個方向走：從背答案，改成理解選擇。\u003C\u002Fp>\u003Cp>我遇過太多人一開口就說「我們用 microservices」。這句話常常只是想讓自己看起來成熟。問題是，microservices 不是免費午餐，它會帶來網路延遲、觀測性、部署協調、失敗模式，還有一堆你原本不用處理的麻煩。很多時候，先用 monolith 反而比較合理。\u003C\u002Fp>\u003Cp>實操時，每次你加一個元件，就強迫自己補一句代價說明。\u003C\u002Fp>\u003Cul>\u003Cli>加 cache，就要說快取失效怎麼辦。\u003C\u002Fli>\u003Cli>加 queue，就要說重試和 dead-letter 怎麼處理。\u003C\u002Fli>\u003Cli>切服務，就要說邊界為什麼值得那個複雜度。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這個習慣很重要，因為它會把你從「畫圖的人」拉回「做決策的人」。\u003C\u002Fp>\u003Ch2>不要亂刷題，先把一種題型練到不陌生\u003C\u002Fh2>\u003Cp>我以前學 system design 的方式很爛，就是一直換題目。今天 YouTube，明天 Uber，後天 Twitter，結果腦袋塞滿一堆彼此不相干的片段。看起來很努力，實際上很散。\u003C\u002Fp>\u003Cp>比較有效的方法，是先挑少數幾種常見題型，反覆練到你看到題目不會慌。像 URL shortener、\u003Ca href=\"\u002Fnews\u002Fasiastrategy-yahoo-finance-page-not-investment-research-zh\">rate\u003C\u002Fa> limiter、chat system、file storage、news feed，這些題型各自會逼你碰到不同問題：讀寫比例、fanout、即時性、一致性、儲存、快取、失敗處理。你不是在背答案，你是在熟悉結構。\u003C\u002Fp>\u003Cp>Azeem 的「from scratch」不是叫你從零知識開始，而是叫你建立一條梯子。先從小系統開始，再往上加複雜度。這樣你才會知道每一塊元件是怎麼互相影響的，不然你只是在聽別人講一個很完整的故事，自己還是不會做。\u003C\u002Fp>\u003Cp>我自己最有感的是 chat system。以前我只會說「訊息存在資料庫，再推送出去」，講得很乾。後來我才發現，offline delivery、訊息順序、重送、ack、同步狀態，全部都會影響設計。你只要把一個題型練熟，下一題就不會那麼像黑盒子。\u003C\u002Fp>\u003Cp>實操寫法：每週只做一題完整設計，然後寫成固定格式。\u003C\u002Fp>\u003Cul>\u003Cli>需求\u003C\u002Fli>\u003Cli>估算\u003C\u002Fli>\u003Cli>資料模型\u003C\u002Fli>\u003Cli>API\u003C\u002Fli>\u003Cli>主流程\u003C\u002Fli>\u003Cli>瓶頸\u003C\u002Fli>\u003Cli>取捨\u003C\u002Fli>\u003C\u002Ful>\u003Cp>你不用每題都追求完美，你只要一直重複同一套思考順序，腦袋就會慢慢長出肌肉記憶。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># system design 練習模板（可直接複製）\n\n## 1. 問題定義\n- 這個產品在解決什麼問題？\n- 誰會用？\n- 核心使用流程是什麼？\n\n## 2. 需求\n### 功能需求\n- \n- \n- \n\n### 非功能需求\n- 延遲目標：\n- 可用性目標：\n- 一致性要求：\n- 擴充性假設：\n\n## 3. 粗略估算\n- 日活：\n- 每人每天請求數：\n- QPS：\n- 讀寫比：\n- 每筆資料大小：\n- 尖峰倍數：\n\n## 4. 核心資料\n- 使用者\n- 主要物件\n- 中介事件\n- 狀態 \u002F session \u002F log\n\n## 5. API 草稿\n- POST \u002F...\n- GET \u002F...\n- PUT \u002F...\n- DELETE \u002F...\n\n## 6. 高層架構\n- Client\n- Load balancer \u002F API gateway\n- App service\n- Cache\n- Database\n- Queue \u002F stream\n- Object storage \u002F CDN\n\n## 7. 資料流\n1. Request 進來\n2. 驗證與授權\n3. 讀 cache 或 DB\n4. 寫入 durable store\n5. 必要時丟 async work\n6. 回應使用者\n\n## 8. 瓶頸\n- 最先會爆的是什麼？\n- 哪裡會熱點？\n- 哪裡最貴？\n\n## 9. 取捨\n- 為什麼選這個 DB？\n- 為什麼 cache 放這裡？\n- 為什麼這段用 async？\n- 為什麼現在還不切 microservices？\n\n## 10. 失敗處理\n- Retry\n- Timeout\n- Dead-letter queue\n- Replication\n- Backup\n\n## 11. 擴充計畫\n- 加 cache\n- 加 replica\n- Partition data\n- Offload static content\n- 真的需要時再拆服務\n\n## 12. 最後總結\n- 一句話設計摘要\n- 最大取捨\n- 最大風險\n- 下一步改善\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段就是我想直接塞給自己的版本。它不會讓 system design 瞬間變簡單，但它會讓你至少知道自己現在在幹嘛，不會一題還沒開始就先亂。\u003C\u002Fp>\u003Cp>這篇內容的原始來源是 \u003Ca href=\"https:\u002F\u002Fcloudwithazeem.medium.com\u002Fhow-to-learn-system-design-from-scratch-05ee48cda5b2\">Azeem 的 Medium 文章\u003C\u002Fa>，我拆的是他的學習順序和觀念；上面的模板、段落重排、實作清單，都是我整理後做成可直接抄的版本。你如果要看原文脈絡，從這個 URL 進去就行。\u003C\u002Fp>","拆解 Azeem 的 system design 學習路線，整理成可直接照抄的練習模板，讓你從亂猜架構變成有順序地拆題。","cloudwithazeem.medium.com","https:\u002F\u002Fcloudwithazeem.medium.com\u002Fhow-to-learn-system-design-from-scratch-05ee48cda5b2",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782849806074-jwd5.png","tools","zh","b80a992a-5a52-4dd1-b1ac-c38de13148bd",[17,18,19,20,21],"system design","distributed systems","capacity estimation","tradeoff","backend interview",[23,24,25],"先定需求和約束，再選架構，不要反過來。","每個元件都要講清楚解決什麼問題與代價。","固定用同一套練習模板，system design 才會變成可重複的技能。",0,"2026-06-30T20:02:56.539095+00:00","2026-06-30T20:02:56.517+00:00","13637d9f-b9a5-40ff-9d37-af2ab7a697f1",{"tags":31,"relatedLang":34,"relatedPosts":38},[32],{"name":18,"slug":33},"distributed-systems",{"id":15,"slug":35,"title":36,"language":37},"system-design-learning-path-from-scratch-en","System design finally clicks with one learning path","en",[39,45,51,57,63,69],{"id":40,"slug":41,"title":42,"cover_image":43,"image_url":43,"created_at":44,"category":13},"dbd4fbc8-282b-4386-aa17-f5719e0f7214","ai-music-prompt-stack-copy-template-zh","AI 音樂先做提示堆疊","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782856113160-hql7.png","2026-06-30T21:47:56.885133+00:00",{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"bb7ecbfb-54b2-405f-8c93-a5cd4e124a30","best-ai-music-generator-2026-ropewalk-zh","2026 AI 音樂生成實作指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782855168859-73vz.png","2026-06-30T21:32:23.2761+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"82a34bad-b215-42bd-a884-4d805e023797","openmontage-agentic-video-production-ready-zh","OpenMontage 證明代理式影片製作已能上線工作","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782854272516-fsew.png","2026-06-30T21:17:21.663369+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"f1187152-abac-4641-93ae-0df5c3f81e12","astryx-open-source-meta-design-system-zh","Meta 開源 Astryx 設計系統","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782842576719-yvre.png","2026-06-30T18:02:23.332763+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"11362fe5-3666-4c78-9685-6393c8130ae2","googles-gemini-live-camera-editing-right-move-zh","Google 把 Gemini 做成即時攝影編輯，這一步是對的","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782838971989-agke.png","2026-06-30T17:02:20.205174+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"e2cbc0d9-63a2-4732-af6b-dc18b1720f0e","manus-ai-pricing-2026-plans-credits-costs-zh","Manus AI 2026 方案與信用點成本指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782835379959-kc71.png","2026-06-30T16:02:28.898341+00:00",[76,81,86,91,96,101,106,111,116,121],{"id":77,"slug":78,"title":79,"created_at":80},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":82,"slug":83,"title":84,"created_at":85},"9b19ab54-edef-4dbd-9ce4-a51e4bae4ebb","mcp-in-2026-the-ai-tool-layer-teams-use-zh","2026 年 MCP：團隊真的在用的 AI 工具層","2026-03-26T08:01:46.589694+00:00",{"id":87,"slug":88,"title":89,"created_at":90},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":92,"slug":93,"title":94,"created_at":95},"05553086-6ed0-4758-81fd-6cab24b575e0","garry-tan-open-sources-claude-code-toolkit-zh","Garry Tan 開源 Claude Code 工具包","2026-03-26T08:26:20.068737+00:00",{"id":97,"slug":98,"title":99,"created_at":100},"042a73a2-18a2-433d-9e8f-9802b9559aac","github-ai-projects-to-watch-in-2026-zh","2026 必看 20 個 GitHub AI 專案","2026-03-26T08:28:09.619964+00:00",{"id":102,"slug":103,"title":104,"created_at":105},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":107,"slug":108,"title":109,"created_at":110},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":112,"slug":113,"title":114,"created_at":115},"bfdb467a-290f-4a80-b3a9-6f081afb6dff","aiml-2026-student-ai-ml-lab-repo-review-zh","AIML-2026：像課綱的學生實驗 Repo","2026-03-27T01:21:51.467798+00:00",{"id":117,"slug":118,"title":119,"created_at":120},"80cabc3e-09fc-4ff5-8f07-b8d68f5ae545","ai-trending-github-repos-and-research-feeds-zh","AI Trending：把 AI 資源收成一張表","2026-03-27T01:31:35.262183+00:00",{"id":122,"slug":123,"title":124,"created_at":125},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]