Search for a command to run...
Articles tagged with #backend
為什麼要讀寫分離？ 大多數的 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 會瞬間承受巨大壓力。 常見場景 惡意攻擊：...
序 當系統架構逐漸成形、程式碼品質也趨於穩定後，下一個遲早會浮現的現實問題：撐得住嗎？ 也許在開發環境一切順暢，但一上線就開始出現以下情境： 使用者一多，API 回應時間明顯變慢 尖峰流量來臨時，資料庫 CPU 飆高、連線數耗盡 某個外部服務偶爾變慢，卻拖垮了整個系統 記憶體持續成長，最後只剩一句「Out of Memory」 這些問題，不是功能寫錯，而是系統沒有「緩衝能力」。 在 Module 4 中，我們將視角從「單一請求的正確性」，提升到「整體系統在壓力下的行為」。我們需要開始...
這堂課我們正式進入 - 結構型模式 的領域。 如果不把這「創建型」模式（工廠、建造者）搞定，我們很難有東西可以「結構化」。但現在我們已經學會怎麼優雅地產生物件了，接下來會遇到的問題通常是：「這個新來的物件，跟我的舊系統插頭不合怎麼辦？」 這就是 Adapter Pattern 的主場。 核心概念：轉接頭 從台灣帶了筆電（三孔插頭）出國旅行。 牆上的插座 (Client 期待的介面)：可能是兩孔圓形，或兩孔扁形。 筆電插頭 (Adaptee 被適配者)：兩孔扁型，一孔圓形。 問題：插不進去，無法供...
