部落格文章

「設計一個 URL 短網址服務」「設計一個訊息系統」——系統設計面試問的不是背答案，而是思考方式。這篇整理了一套可以重複使用的面試框架，並用兩道例題示範如何從需求出發，一步步推導出架構、說清楚取捨。

2026-04-07

平常流量是 1000 QPS，但「開賣」的那一刻，瞬間湧入 50 萬個請求——系統要怎麼活下來？這篇用課程平台的限量課程開賣和直播開播場景，把第 13 篇學到的限流、降級、熔斷，落地到一個真實的高流量設計，走過每個防護層是怎麼工作的。

2026-04-06

ChatGPT 看起來像一個聊天視窗，背後卻有幾個特殊的設計挑戰：回應是串流的、推理非常耗資源、每輪對話要記住上下文、系統要支援幾千萬用戶同時使用。這篇用熟悉的架構思維，拆解 AI 聊天系統的關鍵設計。

2026-04-05

Twitter 的核心功能看起來很簡單：發推文、看動態、按讚留言。但「動態牆」背後藏著一個棘手的設計問題：你追蹤 200 個人，每個人都可能隨時發文——你打開 App 時，那條時序動態要怎麼快速組出來？這篇來看社群動態系統的兩種策略：推（Fan-out on Write）與拉（Fan-out on Read）。

2026-04-04

Uber 的核心問題看起來簡單：乘客在哪、司機在哪、把最近的司機派過去。但背後有幾個棘手的設計挑戰：海量的司機位置每秒更新、要在幾秒內完成司機配對、派單要公平且不重複。這篇用熟悉的架構思維，拆解 Uber 的即時調度系統。

2026-04-03

把前面學到的架構思維，套到 YouTube 上：影片上傳、轉檔、儲存、串流播放、推薦、搜尋——每個環節背後都是熟悉的概念。讀完這篇，你會發現 YouTube 的架構不是魔法，而是我們走過的那些解法，在更大規模下的組合。

2026-04-02

從一台 Server、一個前端、一個後端、一個資料庫，走到現在——讓我們退一步，把這二十幾篇走過的每個元件全部畫出來，看看這個系統到底長成了什麼形狀。這篇不是新概念，而是一次完整的架構回顧：每個元件在哪裡、解決什麼問題、彼此如何連接。

2026-04-01

LLM 的回應不像一般 API，它是一個字一個字生成的。等整段回答生成完才顯示，用戶要等很久；而推理非常耗 GPU，成本高、難擴展。這篇跟著小明，理解串流回應（Streaming）怎麼讓 AI 感覺「即時」、推理服務如何擴展、以及請求佇列在 AI 系統裡的角色。

2026-03-31

課程平台決定加入 AI 學習助理：用戶問問題，AI 根據課程內容回答。這篇跟著小明，理解 LLM 是什麼、為什麼直接用 LLM 會「亂說話」、RAG（檢索增強生成）怎麼把知識庫接進來，以及向量資料庫在這個架構裡扮演什麼角色。

2026-03-30

容器讓每個服務都能標準化部署，但當你有幾十個服務、幾百個容器散落在幾十台機器上，手動管理根本不可能。這篇跟著小明，理解 Kubernetes 是什麼：它不是容器本身，而是「容器的排班員」——決定誰跑在哪台機器、自動重啟崩潰的容器、流量多了自動加副本、讓你宣告「我要這樣」然後它去保持。

2026-03-29

「在我電腦上能跑」是軟體開發的經典詛咒。這篇跟著小明，從環境不一致的部署噩夢出發，理解 Docker 容器在解決什麼問題：為什麼要把應用程式和它的執行環境一起打包？Image 和 Container 的差別是什麼？以及容器化帶來的不只是「到處能跑」，還有部署流程的根本轉變。

2026-03-28

監控能告訴你「哪裡壞了」，但要知道「為什麼壞」，得靠 Log 和分散式追蹤。這篇跟著小明，從一筆跨越五個服務的失敗請求出發，學習結構化 Log 的寫法、Request ID 的設計，以及為什麼要有 Jaeger 或 Zipkin 這類追蹤工具，才能在多服務的叢林裡找到那根斷掉的線。

2026-03-27

系統越複雜，出問題越難靠「感覺」到。這篇跟著小明，從半夜三點的告警電話出發，學習監控系統的三個核心指標（QPS、延遲、錯誤率），理解 Prometheus 怎麼收數字、Grafana 怎麼畫圖，以及告警怎麼設才不會變成「狼來了」或靜悄悄地漏報。

2026-03-26

多台後端一起跑背景任務，有個很現實的問題：同一份工作，可能同時被好幾台機器「認領」，導致 email 重複寄、帳單重複結算、推播重複發送。這篇跟著小明，從「值日生搶掃把」的困境出發，理解分散式鎖與領導者選舉是什麼，以及為什麼會有 Zookeeper、etcd 這類協調服務的存在。

2026-03-25

搜尋做得再好，也解決不了「現在就要知道」的需求：學生交作業，老師要立刻收到通知；老師回覆，學生要馬上看到。這篇跟著小明，從輪詢的天花板出發，理解 WebSocket 為什麼能讓伺服器主動推送；以及當你有很多台後端、很多條長連線時，為什麼還需要 Pub/Sub 把通知送到「正確的那一台」。

2026-03-24

當課程平台長到一定規模，你會發現一件事：不同的資料，其實有截然不同的「天然形狀」。用同一種資料庫硬撐所有需求，就像用同一把工具處理所有事情——不是不行，而是越來越彆扭。這篇帶著小明，認識關聯式、文件型、搜尋引擎、時序資料庫各自擅長什麼，以及為什麼現代系統幾乎都是多種儲存並存。

2026-03-23

讀寫分離加了多個從庫，讀的問題解了，但寫入還是只能打到主庫那一台。當資料量大到一顆 DB 裝不下、寫入量超過單機上限，就是 Sharding 登場的時候了。這篇帶著小明，搞清楚怎麼切、切哪個鍵、切完之後會遇到什麼新麻煩。

2026-03-22

限時特賣靠限流和排隊撐過去了，但 DB 的讀取延遲在特賣結束後依然居高不下。當初做的一主一從，已經跟不上成長的腳步。這篇帶著小明，把單一 Read Replica 擴充成多個，把讀取流量真正分散開來——同時也要搞清楚「複製延遲」這個繞不過去的坑。

2026-03-21

課程平台要辦限時特賣了，預估流量會是平常的二十倍。不限流，後端會被壓垮；不排隊，用戶會看到 500 錯誤；不降級，核心功能會被次要功能拖死。這篇跟著小明，學會在洪水來臨時，怎麼讓系統優雅地活著。

2026-03-20

單體的痛苦已經確認了，但「拆微服務」說起來容易，做起來難。到底要從哪裡下刀？服務邊界怎麼劃才不會越拆越亂？拆完之後，外面的世界要怎麼和這一堆服務溝通？這篇帶著小明，真正動手拆出第一個 Microservice。

2026-03-19

系統越來越大，功能越來越多，小明他們的「單體大程式」開始遇到瓶頸。不是效能問題，而是開發與部署的痛苦：改個小地方也要全站重傳、一人寫錯全站掛掉。這篇來聊聊為什麼我們會開始考慮「拆分服務」。

2026-03-18

當系統跨越多台機器、多個地區運作，你沒辦法同時擁有完美的一致性、可用性、與分區容錯。你只能三選二。這篇用開分店、帳本同步的比喻，帶你理解 CAP 定理，以及實務上大家的取捨。

2026-03-17

把網站擴充成多台伺服器後，卻發生「登入後重整網頁又被登出」的詭異 Bug？這是因為每一台伺服器各自記住了不同的「狀態」。這篇我們來聊聊什麼是有狀態（Stateful）與無狀態（Stateless），以及分散式系統如何處理 Session。

2026-03-16

當瞬間湧入大量訂單，廚房來不及做又不能拒絕客人怎麼辦？引入「排隊區」讓訂單一張張慢慢做。這篇來談 Message Queue（訊息佇列）如何做到非同步解耦與削峰填谷，保護脆弱的資料庫與後端。

2026-03-15

每次有人買課，系統都要發 Email 確認信。但寄信 API 很慢，導致使用者結帳後看著轉圈圈等很久。把「寄信」這種耗時但不需馬上看到結果的任務，交給背後的專人（Worker）處理，這就是同步與非同步的差別。

2026-03-14

把常問的菜單寫在 Redis 擋住了查詢的壓力，但如果是真正需要寫入帳本的動作（下單、註冊）變多，大家還是要排隊等同一本帳本。這篇來談讀多寫少系統的必經之路：讀寫分離與主從複製。

2026-03-13

每次有人進首頁查「精選課程」，資料庫都要翻整本帳本找出來算一次。既然大家都常看且不常變，不如把這些熱門資料寫在小黑板（Redis）上。這篇來談什麼該快取、快取失效策略，以及常見的打穿與雪崩危機。

2026-03-12

課程列表、熱門排行查詢變慢，DB 回應時間拉長。帳本越翻越厚，常查的項目若沒做目錄就會慢。加索引、改 query、減少不必要的 join，先在不加機器的前提下把 DB 負擔降下來，為後面的讀寫分離與快取打底。

2026-03-11

單機快撐不住了，要先升級 CPU、記憶體，還是加第二台、第三台後端？什麼叫垂直擴充、水平擴充？若選水平，前面要擺誰來分流？Nginx 做負載平衡與反向代理的角色，以及選水平之後會遇到的新問題。

2026-03-10

用戶變多了，首頁變慢、有時 504。什麼叫負載、什麼叫瓶頸？怎麼判斷是後端還是資料庫在扛不住？從變慢、超時、錯誤變多裡，學會「感覺」到系統需要改變。

2026-03-09

系統設計系列的起點：用線上課程平台來說明一個前端、一個後端、一個資料庫。請求怎麼走？什麼叫單體架構？為什麼在用戶少的時候就夠用？

2026-03-08

一個前端工程師的系統設計學習之旅。為什麼系統設計重要？這個系列會討論什麼？用一個網站長成帝國的故事，從一前一後一 DB 走到分散式架構，給大家一個宏觀的起點。

2026-03-07

從追求完美平衡到接受失衡，從自我懷疑到找回初心。Hannah 的分享讓我明白，在育兒與職涯的拉扯中，我們並不孤單。

2025-12-14

接案前先思考，準備充足才不會慌！從動機檢視到風險評估，從期待調整到準備清單，幫你在跳入接案世界前，先做好充分的思考和準備，讓接案之路走得更順暢。

2025-10-19

從 useState 到 Context API，React 內建狀態管理已經很強，但為什麼還需要外部套件？讓我們從實際開發痛點來分析。

2025-10-19

從 setState 到 prop drilling，再到 Context API，理解 React 為何需要外部狀態管理。

2025-10-19

從研究室走進辦公室，目前所學的程式能力能派上用場嗎？學術背景真的能換成職場實力嗎？畢業前的你以為最大的挑戰是論文，但真正的考驗，其實才剛開始。

2025-10-16

只有全職接案才是成功的接案？自由接案只能有一種形狀嗎？

2025-09-11

你是否也思考過，除了朝九晚五的上班生活之外，我還可以怎麼開創新職涯？

2025-08-07

7/16 我在臉書社團宣傳新書《不想上班的勇氣》上市時，有位讀者提出了一個犀利的問題「請問怎麼樣才可以不上班？但我看作者的簡介還是在公司上班...」

2025-07-16

當客戶瘋狂殺價、質疑專業時，你該堅持什麼、又該讓出什麼？從真實談判經驗出發，教你看懂殺價背後的心理，建立對等、有底線的合作關係。

2025-07-11

AI 的崛起確實讓許多工程師感到焦慮，擔心自己的工作會被取代。但仔細觀察會發現，麻瓜與工程師之間的專業鴻溝，並非單純靠 AI 就能彌補。

2025-07-03

從如何找到第一個客戶、避開新手常見陷阱，到建立穩定接案管道的具體方法，一步步帶你走出辦公室牢籠。當你能用專業技能自由工作，不必再看老闆臉色，每天起床的鬧鐘聲都會變得悅耳。這不是幻想，而是可以實現的職涯新選擇。現在就開始規劃你的自由工作藍圖，讓你的專業真正為自己創造價值。

2025-07-01

在個人和小型團隊的接案市場中，僅僅掌握前端、後端或設計技能並不足以保證成功。更多的挑戰在於如何應對現實中的各種情境及困難。成功很難被複製，但是失敗可以。本演講將從失敗學的角度出發，分享接案小白在接案過程中可能遇到的各種意料之外的狀況，以及如何從這些經歷中學習與成長。

2024-12-28

兩個或兩個以上的 component 結合成一個擁有特定功能或是能夠達成特定任務的 component。

2024-04-30

Container/Presentational 模式是一種強制分離關注點的設計模式。這個模式的核心思想是將視圖（Presentational）與應用程式邏輯（Container）分開。

2024-04-30

把一個 function 當作子元素（children）傳給元件，這個 function 會在元件內部被呼叫，並且可以取得元件內部的狀態或資料，然後回傳你想要渲染的內容。

2024-04-30

Higher-Order Component，將可重複使用的邏輯作為 props 傳遞給整個應用程式中的元件

2024-04-30

讓你不必寫 class 就能使用 state 以及其他 React 的功能

2024-04-30

擁有 render prop 的元件接受一個「返回 React 元件的函數」，而不是實現自己的渲染邏輯。在渲染時，該元件呼叫這個函數，並使用它返回的 React 元件。

2024-04-30

如果十年後我還是跟現在差不多，那絕對不會是我自己期待的樣子，所以今天也想特別留下一點記錄，一方面不要忘記自己這次得到的收穫，另一方面也不斷提醒自己，努力不要成為十年後想起當年會後悔的模樣。

2023-08-13

刻一套元件庫，到底難不難？自己做一套有什麼好處？過程當中需要考量哪些部分？今天要跟大家分享那些在做元件庫的過程當中，自己可以做得更好的部分，以及那些被我忽略而犯蠢的小細節。

2023-05-24

今天要來揭開從無到有，出版一本 iThome 鐵人賽系列書籍的神秘面紗。

2022-11-09