Search for a command to run...
Series
“從 Rookie 到 Junior：一個後端成長的 30 堂課” 是一套專為後端新手所設計的成長型技術系列文章。內容以實務為導向，逐步拆解後端工程的核心能力，包括程式語言基礎、架構思維、框架運作原理、業務邏輯設計、資料庫操作、以及常見的開發模式。
本系列的目標是協助讀者從零散的學習堆疊，建立成體系的後端知識框架。讀者能夠理解各語言背後不變的工程思維與設計原則。這套內容旨在讓學習者從「會寫程式」進入「能理解系統設計」的階段，逐步具備勝任 Junior Backend Engineer 的能力。
當這幾個名詞出現後，代表我們進到了一個高併發/大流量的系統了。在這個章節中，我們一起來看看如何透過一些方式來避免高併發導致我們的系統crash掉。 限流(Rate Limiting) 相信大家對這個名詞並不陌生，限流其實就是字面上的含意，限制流量。 限流的目的是保護「接收方」，確保系統不會因為瞬間的高併發請求而癱瘓。 限流通常發生在 API Gateway 或服務的最前端。它像是一個夜店門口的保全
過去我們討論了 要把程式寫在哪、程式要怎麼拆的題目，接下來我們來看看「如何服務不同客戶」，這些架構反映了軟體開發在擴充性與複雜度之間的權衡。 軟體架構深度解析：從系統拆分到商業規模化 在軟體工程的演進中，架構的選擇往往是在「開發效率」、「系統擴充性」與「營運成本」之間尋求平衡。我們可以從兩個核心維度來觀察這些架構：系統如何運行（單體 vs. 分散式） 以及 如何服務客戶（單租戶 vs. 多租戶）。
為什麼要讀寫分離？ 大多數的 Web 應用都是 「讀多寫少」（例如：看文的人多，發文的人少,Heavy Read System）。當所有的請求都塞給同一台資料庫時，磁碟 I/O 和連線數會成為瓶頸。 Master (主庫)： 負責寫入 (Insert/Update/Delete)，確保數據一致性。 Slave (從庫)： 負責讀取 (Select)，可以有多個從庫來分擔讀取壓力。 為什麼讀
佇列 佇列的實作工具非常多，舉凡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 溝通，所有的數據流動都由應用程式的程式碼來控制。 這就像去圖書館借書： ...
