自動擴縮讓容量跟著負載走：忙時加機器、閒時收回來，省成本又扛尖峰。但它不是萬靈丹——擴縮有延遲、有下限、會被冷啟動與下游瓶頸卡住。它買的是彈性，不是「無限容量」。
🧠 Intuition
TIP
擴縮是個控制迴路：量一個訊號（CPU、QPS、佇列長度）→ 比對目標 → 加減副本。訊號選錯、反應太慢，迴路就會震盪或追不上尖峰。
- 水平擴縮（scale out/in）：加減副本，需服務無狀態；最常用。
- 垂直擴縮（scale up/down）：換更大的機器；有上限、常要重啟。
- 擴縮指標要選「貼近瓶頸」的：CPU 密集型看 CPU，I/O 等待型該看佇列長度或並發數，否則擴了也沒用。
⚖️ Tradeoffs
只靠反應式擴縮（reactive）— 入門但會被尖峰打臉
- 等指標超標才擴 → 新副本還在冷啟動（拉映像、暖快取、JIT），尖峰已經把現有副本打爆。
- 流量階梯式暴衝（如秒殺、推播）時，反應式幾乎一定來不及。
反應式 + 預測式 + 容量下限（headroom）— 穩健組合
- 設最小副本數保留 headroom，吸收擴縮延遲與突發。
- 對可預期的尖峰（行銷活動、整點）用排程/預測式預先擴。
- 仍要配 限流 / 熔斷 / 負載卸除：擴縮有上限，過載時得能優雅降級，而不是無止境加機器把成本與下游一起拖垮。
- 代價：headroom 與預測式都在花錢買保險；參數（門檻、冷卻時間）要調，否則會抖動（thrashing）。
🔑 Takeaways
- 自動擴縮是控制迴路，指標要貼近真正的瓶頸（不一定是 CPU）。
- 純反應式擋不住階梯式尖峰——用最小副本 headroom + 預測式預擴補上擴縮延遲。
- 擴縮有上限，務必搭配限流/熔斷/負載卸除；過載時要能降級，而非無限加機器。
No notes yet — jot your takeaways or Q&A here.