Search for a command to run...
當這幾個名詞出現後，代表我們進到了一個高併發/大流量的系統了。在這個章節中，我們一起來看看如何透過一些方式來避免高併發導致我們的系統crash掉。 限流(Rate Limiting) 相信大家對這個名詞並不陌生，限流其實就是字面上的含意，限制流量。 限流的目的是保護「接收方」，確保系統不會因為瞬間的高併發請求而癱瘓。 限流通常發生在 API Gateway 或服務的最前端。它像是一個夜店門口的保全
過去我們討論了 要把程式寫在哪、程式要怎麼拆的題目，接下來我們來看看「如何服務不同客戶」，這些架構反映了軟體開發在擴充性與複雜度之間的權衡。 軟體架構深度解析：從系統拆分到商業規模化 在軟體工程的演進中，架構的選擇往往是在「開發效率」、「系統擴充性」與「營運成本」之間尋求平衡。我們可以從兩個核心維度來觀察這些架構：系統如何運行（單體 vs. 分散式） 以及 如何服務客戶（單租戶 vs. 多租戶）。
為什麼要讀寫分離？ 大多數的 Web 應用都是 「讀多寫少」（例如：看文的人多，發文的人少,Heavy Read System）。當所有的請求都塞給同一台資料庫時，磁碟 I/O 和連線數會成為瓶頸。 Master (主庫)： 負責寫入 (Insert/Update/Delete)，確保數據一致性。 Slave (從庫)： 負責讀取 (Select)，可以有多個從庫來分擔讀取壓力。 為什麼讀
從2025年3月開始，我陸陸續續參與了從新創到上市櫃公司的Senior - Tech Lead的相關面試，其中有不乏 尊重面試者、展現高度專業的企業(公司)，當然也有遇到幾場面試鬼故事，這篇文章主要分享我對於軟體工程師面試的方向分享，以及部分鬼故事，以此警惕自己不要成為這樣的面試官。 AI的洪流，改變了SWE的生態 LLM的發展確確實實的影響到了軟體工程師的生態。 過去受限於算力與資料規模，深度學
佇列 佇列的實作工具非常多，舉凡AWS SQS、RabbitMQ、Kafka…等。 佇列的特性，其實是一個非常強大的系統緩衝區，應用層面非常廣。 什麼是佇列？ 佇列可以想像成，在既有流程中外，有另一個”水管”，來連接原有的資料流(或邏輯過程)，其中 呼叫方將資料 推(Push)到水管中，接受方(監聽) 從水管中將資料拉(Pull)出處理 為什麼佇列是「強大的緩衝區」？ 在同步處理中，系統像是一
我們在上一篇文章中介紹了基本的Cache Aside Pattern，也補充了在Database 主從分離架構下可能造成Cache的異常，並一同介紹了：延遲雙刪 以及 CDC。 我們這個章節要來談談Cache還有哪些問題 快取穿透 (Cache Penetration) 定義 請求的資料 不在快取中，也不在資料庫中。 每次請求都會穿過快取，直接打到 DB，但 DB 也查不到資料，導致無法回寫快取。如果有惡意攻擊者使用大量不存在的 ID 進行攻擊，DB 會瞬間承受巨大壓力。 常見場景 惡意攻擊：...
在後端開發的世界裡，有一句至理名言：「沒有什麼效能問題是加一層 Cache 不能解決的；如果有，那就加兩層。」 雖然是句玩笑話，但道出了後端架構的核心思想——「以空間換取時間」。資料庫（Database）存放在硬碟，讀取速度慢且 I/O 成本高；而快取（Cache, 如 Redis）存放在記憶體（RAM），讀取速度極快但空間昂貴。 什麼是 Cache-Aside Pattern？ Cache 不會主動和 Database 溝通，所有的數據流動都由應用程式的程式碼來控制。 這就像去圖書館借書： ...
序 當系統架構逐漸成形、程式碼品質也趨於穩定後，下一個遲早會浮現的現實問題：撐得住嗎？ 也許在開發環境一切順暢，但一上線就開始出現以下情境： 使用者一多，API 回應時間明顯變慢 尖峰流量來臨時，資料庫 CPU 飆高、連線數耗盡 某個外部服務偶爾變慢，卻拖垮了整個系統 記憶體持續成長，最後只剩一句「Out of Memory」 這些問題，不是功能寫錯，而是系統沒有「緩衝能力」。 在 Module 4 中，我們將視角從「單一請求的正確性」，提升到「整體系統在壓力下的行為」。我們需要開始...
這堂課我們正式進入 - 結構型模式 的領域。 如果不把這「創建型」模式（工廠、建造者）搞定，我們很難有東西可以「結構化」。但現在我們已經學會怎麼優雅地產生物件了，接下來會遇到的問題通常是：「這個新來的物件，跟我的舊系統插頭不合怎麼辦？」 這就是 Adapter Pattern 的主場。 核心概念：轉接頭 從台灣帶了筆電（三孔插頭）出國旅行。 牆上的插座 (Client 期待的介面)：可能是兩孔圓形，或兩孔扁形。 筆電插頭 (Adaptee 被適配者)：兩孔扁型，一孔圓形。 問題：插不進去，無法供...
