鐵人檔案
系統設計很像在打九頭蛇：以為砍掉了一個瓶頸，下一秒馬上又冒出新的頭。這系列用 30 天，從最陽春的「瀏覽器 -> Server -> Database」出發，看著一個社群網站隨使用者變多、流量變大，逐一解決系統長大時遇到的問題。這不是一份元件清單，而是練習在每個當下看清真正的瓶頸，選出當下最合理的取捨。
這系列文章想陪大家一起做一件事：從零開始設計一個名為 PokeThreads 的社群平台（參考自 Meta 的 Threads），並且讓它隨著使用者變多、流量變...
上一篇估算出來的流量其實非常小，每秒寫入大概 1~2 次、讀取大概 100 多次，這種規模不需要任何花俏的架構，先做出一個 「堪用」 的版本就好。 這也是這個系...
昨天做出了最陽春的 PokeThreads，但故意跳過了一個問題： GET /feed 這支 API 收到 Request 之後，到底該回傳哪些貼文？ Fee...
昨天把 Feed 的核心邏輯做出來了，GET /feed 已經能正確回傳 Pikachu 追蹤的人發的貼文，但那時候刻意跳過了一個問題：這支 API 到底該回傳...
這幾天我們把最陽春的 PokeThreads 做出來了，也解決了 Feed 該回傳什麼內容的問題，但整個架構其實還停留在最原始的狀態： 瀏覽器 -> Se...
昨天我們把 Application Server 從一台擴展成多台，靠 Load Balancer 分攤流量： 這解決了單台 Server 的容量問題，但當時...
前幾天把 Application Server 從一台變成多台，也把 Session 從 Server Memory 搬到共用的 Session Store：...
目前 PokeThreads 的架構已經有多台 Server 和 Primary / Replica Database： Read 壓力被 Replica 分...
前面幾天，PokeThreads 的架構已經逐漸長成分散式系統的樣子，但焦點始終放在文字貼文要怎麼被處理跟讀取，現在想加入一個很自然的新功能：讓使用者也能上傳圖...
昨天把 CDN 接上了 PokeThreads，圖片跟影片不再經過 Application Server，直接由 CDN 搭配 Object Storage 提...
