從草臺班子到架構思維：為什麼我要開始學 System Design
前言 / Introduction 工作上經常會寫一些自動化小工具，去解決日常的問題，開發過程不免俗與其他同事的專案有重疊的功能，因此會互相 Code Review，但此時常會覺得羞於見人，既沒有 Diagram 描述架構，文件描述又異常地空乏，總覺得少了點甚麼。 一開始我會覺得：「反正只是個小工具嘛」，但當聽到大神們聊起「模組設計 OOP」、「可維護性」、「容錯設計」等架構問題時，才意識到，我寫的不是工具，是妥協出來的程式碼。 初期的盲點：解決問題 ≠ 解決得好 對我來說，小工具只要「能跑」、「能交差」，就算完成。但這樣的 mindset 讓我忽略了幾件事： 沒人看得懂的 code，會變成團隊的負債 架構思慮不周，容易留下技術債 擴充性很低，重構等於打掉重練 沒有良好的錯誤處理、資源釋放、IO timeout 大神們思考的是「系統的運作」，而不是「功能的存在」 有一次 Code Review，學長只用兩句話，就打醒我： Function 過度耦合，缺乏可維護性和可擴展性 架設方式過於複雜，沒考慮使用者的背景 這時我才發現，System Design 不是只有在面試時才會遇到的 buzzword，它是真正在工作中，讓專案變得可靠、可維護的核心能力。 我為什麼決定開始學習 System Design 技術長大了，但腦袋沒長大：寫得出複雜的程式碼，但無法抽象出整體結構 專案開始有接觸多人合作：你不能只靠自己看懂，還要讓別人接得下去 我想寫出讓人放心的程式，而不是「現在能跑，之後爆炸的程式」 學習路線 我規劃一個 System Design Study Plan，希望能夠利用空閒的時間去補齊這些知識。 週次 主題 核心關鍵詞 重點問題 Week 1 Scalability & Load Balancer Vertical / Horizontal Scaling, Auto Scaling, Round Robin, IP Hash 如何應對高併發？如何分散負載？ Week 2 Cache 設計與策略 Read-Through, Write-Through, TTL, LRU, Redis 如何用 Cache 提高效能又保持一致性？ Week 3 Database 選型與 Sharding SQL vs NoSQL, Sharding, Replication, CAP 什麼情況選 MySQL？什麼情況拆 DB？ Week 4 Data Consistency & Message Queue Eventual Consistency, Kafka, RabbitMQ, Idempotency Key 系統怎麼確保資料一致？怎麼防重複？ Week 5 Rate Limiting & Circuit Breaker Token Bucket, Leaky Bucket, Retry, Backoff, Hystrix 如何保護系統不被濫用或雪崩？ Week 6 CDN & Global System Design Cloudflare, Geo DNS, Edge Cache 如何設計給全球用戶？如何用 CDN 加速？ Week 7 Monitoring & Reliability SLA, SLO, SLI, Prometheus, Grafana, Healthcheck 如何設計一個穩定且可觀察的系統？ Week 8 Design Real Systems & Interview Case Design YouTube, Messenger, TinyURL, LLM Infra 如何答出一個完整的系統設計題？ 結語 System Design 不只是為了寫出能跑的系統，而是為了寫出能活得久的系統。 ...