Search for a command to run...
歡迎來到後端工程師的練功房。很多人以為後端開發就是寫寫邏輯、把資料塞進資料庫就好。但在工程師眼裡，資料庫的設計往往決定了系統的生死。程式碼寫得再漂亮，如果資料庫設計不良（Schema），系統早晚會因為效能瓶頸（Performance）或資料不一致（Inconsistency）而崩潰。
在 Module 1 中，不會出現基礎的 SQL 語法與 CRUD 指令。我們要從「架構面」切入，先談談如何在程式碼中安放資料邏輯，接著深入「儲存面」的選擇題：何時該用 RDBMS？何時該用 NoSQL？
我們將帶你掌握資料庫的選型策略，探討如何在強一致性、弱一致性與最終一致性之間，根據不同的業務情境做出最佳權衡（Trade-off）。最後，我們會從最基本的正規化設計美學，一路談到面試與實戰最常遇到的效能調優與並發難題。
No comments yet. Be the first to comment.
“從 Rookie 到 Junior：一個後端成長的 30 堂課” 是一套專為後端新手所設計的成長型技術系列文章。內容以實務為導向，逐步拆解後端工程的核心能力，包括程式語言基礎、架構思維、框架運作原理、業務邏輯設計、資料庫操作、以及常見的開發模式。 本系列的目標是協助讀者從零散的學習堆疊，建立成體系的後端知識框架。讀者能夠理解各語言背後不變的工程思維與設計原則。這套內容旨在讓學習者從「會寫程式」進入「能理解系統設計」的階段，逐步具備勝任 Junior Backend Engineer 的能力。
想精通一件事情，就逼自己教會別人。 這個系列會關注在開發過程中的概念，實作方式，因此並不會涉及 環境架設 最近閱讀了《The Diary of a CEO: The 33 Laws of Business and Life》，書中有一個概念讓我深受啟發：「想精通一件事情，就逼自己教會別人。」 這個系列文章的誕生，源於我最近帶領的幾位新進工程師。我想，如果這些經驗傳承只停留在公司內部的教育訓練，能受益的僅有寥寥數人；但若能將這些內容整理成公開文章，或許能幫助更多正處於迷惘期的開發者。 因此，這 ...
當這幾個名詞出現後，代表我們進到了一個高併發/大流量的系統了。在這個章節中，我們一起來看看如何透過一些方式來避免高併發導致我們的系統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)出處理 為什麼佇列是「強大的緩衝區」？ 在同步處理中，系統像是一
