一句話總結 TL;DR
影片用「丁丁泡沫紅茶」從一人小店擴張到五百家分店的故事，比喻後端系統從單機到大型架構的演進；重點不是背技術名詞，而是產品變慢當機時能判斷瓶頸在哪，因為快取、優化這些 AI 都能幫你做。
從一人小店到第一個瓶頸
- 能動跟能撐住大量使用者是兩回事：自己用正常，一上線就變慢當機 00:00
- 初始架構最簡單也最脆弱：前端、後端、資料庫加檔案儲存 01:11
- 客人破百後點一杯從三分鐘變半小時：後端邏輯開始卡住 01:29
- 先盤點慢在哪一步，別急著加機器 01:38
加機器 vs. 資料庫優化
- 加人加機器叫垂直擴展 Scale up：CPU 不夠升兩顆，記憶體不夠加大 02:00
- Scale up 的代價是貴又常閒置：只有尖峰用得到，多花冤枉錢 02:09
- 優化第一步是資料庫不是升機器：資料一散亂建索引就變快 03:01
- 請 AI 檢查索引、N+1 query、避免 select * 03:14
快取 cache：把熱資料放記憶體
- 把常用食材放前場就是快取：省下每次跑後場拿料的時間 03:27
- 快取快是因為資料放在記憶體：讀取速度是硬碟的十倍以上 03:47
- 快取空間有限只放最熱資料：如熱門貼文、最新消息 03:47
- 快取要定期更新避免舊資訊：按讚數、留言數都會變動 04:20
- 多數網站做到快取這層就夠了 04:20
開分店的前置作業：水平擴展
- 先把倉庫系統從機器分離：資料庫用 RDS、快取用 ElastiCache、圖片放 S3 05:17
- Docker 確保每臺機器環境一致：AWS 上用 ECS 跑容器 05:27
- CI/CD 免手動更新上百臺機器：推 main 後自動建置測試部署 05:40
- 負載平衡器把流量分散到各機器：最簡單是輪流分配 06:10
- 前置好後改個數字就水平擴展：auto scaling 依 CPU 用量自動擴 06:44
主庫瓶頸、微服務、CDN 與限流
- 五百分店同時連主資料庫會當機：升級只是換成更貴的瓶頸 07:05
- 讀寫分離用副本庫 replica 分擔：讀走副本、寫進主庫保持一致 07:49
- replica 適合多人查、不適合多人同時改 08:09
- 依業務邊界拆成微服務 microservice：單一服務故障不拖垮全系統 08:44
- 靜態內容放各節點就是 CDN：從最近節點取圖片、影片、CSS、JS 09:35
- Vercel、Cloudflare 已自帶 CDN：推上去就有不用另設定 09:47
- 搶購用 rate limiter 加 queue 保護：限流控人數、排隊依序處理訂單 10:24
金句與關鍵數據 Quotes & Numbers
- 真正重要的不是記住多少技術名詞，而是產品變慢當機時你能不能知道問題出在哪——影片的核心結論 11:41
- 技術 AI 都能幫你做，但前提是你要知道現在該解決的問題是什麼——作者對 AI 時代的提醒 11:57
總結與行動建議 Takeaways
- 先判斷瓶頸在哪，再談解法：架構都是被新問題逼出來的
- 別以為上線就能躺著收錢：能動不等於能撐住流量
- 記住優化的推進順序：資料庫、快取、水平擴展、replica、微服務、CDN、限流
- AI 能幫你做快取與優化：前提是你知道當下該解決什麼
- AI 時代稀缺的不是寫程式能力：而是判斷問題出在哪的能力