前言 / 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 不只是為了寫出能跑的系統，而是為了寫出能活得久的系統。
每一個亂七八糟的 script 都可能是未來災難的起點；每一次設計上的思考，都是朝「大神」跨進的一步。