點解你用 AI 寫嘅網站，一出街就即刻冧檔？

好多人以為用 AI 寫好網站，Deploy 上線就可以印印腳等收錢💰。但現實係，自己 Local 試用就順到爆，一掟出街多幾十個 Concurrent Users 入去，個網就慢到嘔，甚至直接死機！💀
其實，「Code 識得郁」同「頂得住大流量 (High Concurrency)」完全係兩個層次。今日同大家拆解純技術向嘅「後端架構演進史」，睇下 System 係點樣由 Single Node 一步步 Scale 到百萬流量級別！🚀
🛠️ 後端系統進化史：由單機到高可用架構
🖥️ 1. 單體架構 (Monolithic / Single Node) 一開始最簡單：Frontend、Backend (例如 Next.js / Node.js) 同 Database 全部塞喺同一部 Server。流量細冇問題，但 Request 一多，CPU 同 RAM 就會瞬間爆滿，直接 502 Bad Gateway。
💪 2. 垂直擴展 (Scale Up) 最直接嘅暴力解法：加錢升級 Server 規格（加 CPU Core、加大 RAM）。雖然見效快，但 Hardware 有物理極限，而且成本極高，Traffic 低谷時資源會嚴重浪費。
🗄️ 3. 資料庫優化 (Database Optimization) 未急住升級機器前，先 Review 吓 DB。幫 Database 加 Index (索引)、避免 N+1 Query 問題、優化 SQL 語句。DB I/O 快咗，整體 Response Time 自然會跌。
⚡ 4. 導入快取層 (Caching Layer) 每次 API 都要 Hit DB 其實非常耗資源。引入 In-memory Cache (例如 Redis)。將最常用、最 Hot 嘅 Data 放落 RAM 度，讀取速度比 Disk 快十倍以上，大幅減輕 DB Loading。
⚖️ 5. 水平擴展與負載平衡 (Scale Out & Load Balancing) 單機頂唔順就要加機。將 Server 程式打包成 Docker 確保每部機環境一致。然後喺最前面加隻 Load Balancer (LB)，將瞬間湧入嘅 Request 平均派發去後面多部 Application Servers，確保冇一部機會做到死。
📖 6. 讀寫分離 (Read/Write Splitting) Web App 通常係「讀多寫少」。如果所有 Servers 一齊 Hit 同一個 Master DB，DB 依然會成為樽頸。解法係起 Read Replicas (副本)，Master 專責 Write (確保 Data 一致性)，Replicas 專責 Read，分攤 Query 壓力。
🧩 7. 微服務架構 (Microservices) System 越寫越大，將唔同嘅 Domain Logic (例如 User Auth, Payment, Notification) 拆分成獨立嘅 Microservices。咁樣就算 Payment Service 冧咗，都唔會拖死成個網頁，而且每個 Service 可以獨立 Deploy 同 Scale。
🌍 8. 內容傳遞網路 (CDN) 靜態資源 (Images, Videos, JS/CSS) 唔好經自己部 Server 出。利用 Cloudflare (Pages / Workers 等) 呢類 CDN 派發，由全球最近 User 嘅 Edge Node 直接 Return 檔案，慳自己 Server Bandwidth 兼極速載入。
🚧 9. 限流與非同步處理 (Rate Limiting & Message Queue) 遇到秒殺級別嘅高併發，要喺最外層做 Rate Limiting 阻擋超額 Request。入到嚟嘅 Request 掉入 Message Queue 排隊，Backend Worker 再慢慢非同步 (Async) 消化訂單，死保 DB 唔好俾人瞬間打爆！
💡 總結
AI 確實好勁，你俾足 Context，佢幫你寫 Code、寫 Dockerfile、甚至出埋 Server Config 都得。但大前提係：當 System 塞車死機嗰陣，你必須具備「架構思維」，知道樽頸 (Bottleneck) 究竟喺邊個位，先可以俾到準確嘅 Prompt 叫 AI 幫你對症下藥！