鐵人檔案
系統設計很像在打九頭蛇：以為砍掉了一個瓶頸，下一秒馬上又冒出新的頭。這系列用 30 天，從最陽春的「瀏覽器 -> Server -> Database」出發，看著一個社群網站隨使用者變多、流量變大，逐一解決系統長大時遇到的問題。這不是一份元件清單，而是練習在每個當下看清真正的瓶頸，選出當下最合理的取捨。
昨天在討論 Fan-out 時提到，擁有幾千萬追蹤者的帳號一發文，就可能讓 Fan-out on Write 的寫入量瞬間爆炸，所以今天就把這個狀況抽出來單獨討...
我們的 PokeThreads 走到現在，已經是一個具備 Load Balancer、Stateless Server、Sharded Database、Cac...
PokeThreads 裡有一種資料，我們從很早就開始提到，卻從來沒有認真設計過，就是計數（Counter）。 Day 8 討論 Cache 的時候，用 Lik...
Day 11 我們做出了最陽春的 Notification，Day 12 用 Message Queue 把它從同步流程裡拆了出去： Like API 只負責...
走過這麼多次的設計與迭代，PokeThreads 已經不是一個「單純」的系統了。 一個 GET /feed Request，背後可能經過： API Gatewa...
前面內容幾乎都在講後端，今天把視角切回前端。 回想 Day 3，我們的 Feed API GET /feed?cursor=abc123&limit=2...
到目前為止，我們的 PokeThreads 已是一套有相當程度的分散式系統，元件包含 Load Balancer、Stateless Server、Read R...
前面我們都在處理使用者變多的問題。今天討論資安層面，換一個角度提問： 「如果有人存心想搞垮這個系統，或是想從裡面偷走一些不該拿到的東西，他會從哪裡下手？」...
昨天盤點了 PokeThreads 的攻擊面，列出幾個明確的缺口：擋不住分散式的爬蟲與洗版、看不懂檔案內容、管不到內部服務之間的信任、也完全沒有「這個人能不能做...
30 天前，這個系列是從一句話開始的： System Design 的第一步，不是畫架構圖，而是先把問題問清楚。 今天是最後一天，與其再加一個新元件，不如看...
