鐵人檔案
系統設計很像在打九頭蛇：以為砍掉了一個瓶頸，下一秒馬上又冒出新的頭。這系列用 30 天，從最陽春的「瀏覽器 -> Server -> Database」出發，看著一個社群網站隨使用者變多、流量變大，逐一解決系統長大時遇到的問題。這不是一份元件清單，而是練習在每個當下看清真正的瓶頸，選出當下最合理的取捨。
前面幾天，PokeThreads 的架構已經慢慢演化成分散式系統，不過所有功能都還圍繞在「發文、讀文」上。 只有這麼簡單的功能，實在太像古早時期的社群網站，今天...
昨天做出了最陽春的 Notification System，採用最直接的同步方式： Charmander -> POST /posts/:id/like...
到目前為止，PokeThreads 已經具備了 Load Balancer、Read Replica、Cache、Stateless Server、CDN 與...
昨天把 Notification 從 PokeThreads 的 Monolith 拆成了獨立的 Notification Service，跟原本的 API S...
昨天在 API Gateway 的職責清單裡，提到它很適合順便做 Rate Limiting，但只是輕輕帶過。今天把這件事攤開來講清楚。 為什麼需要限制流量 限...
PokeThreads 走到今天，已經不是一個單純的 CRUD 小玩具了，但從 Day 2 開始，Database 一直都是同一種選擇，也就是 SQL。這時候很...
昨天討論 SQL 該不該換成 NoSQL，最後留下一個疑問，一旦資料開始分散在不同種類的 Storage 上，SQL、NoSQL、Cache 各存一部分。 怎...
Day 17 用 CAP Theorem 收尾時提到一句話：這條線會一路貫穿到後面 Sharding、Counter System 這些主題。今天就從 Shar...
昨天把 Database 拆成多個 Shard，解決了單一 Database 裝不下所有資料的問題。 今天把這個概念套用在一個具體場景上——Follow 功能，...
今天回頭加強 Feed 功能，看看原本陽春的做法會有什麼問題。 先回顧原本的做法 Day 3 我們做出了最陽春的 Feed 邏輯： SELECT * FROM...
