在系統設計裡，有一個幾乎被所有人低估、卻決定一切上限的基本單位：
HTTP Request
多數人對它的理解停留在：
Client 發送請求 → Server 回傳 Response
但在真實世界裡，一個 HTTP Request 遠遠不只如此。
它會穿越網路、佇列、執行緒、服務、資料庫、快取，
並在每一層留下延遲、風險與成本。
如果你看不懂 Request 的生命週期，你就無法真正理解：
為什麼系統會慢
為什麼多加服務反而不穩
為什麼流量一大就一起死
一、什麼是 HTTP Request Lifecycle？
HTTP Request Lifecycle 指的是：
從使用者「發出請求」開始，到「回應送回使用者」為止，
這個請求在整個系統中經歷的完整路徑與狀態變化。
它不是一行程式碼，而是一條跨越多層系統邊界的旅程。
二、從使用者開始：Client 端其實已經在影響系統了
1️⃣ DNS Lookup
使用者輸入網址
DNS 解析將 Domain 轉成 IP
這一步就可能失敗或延遲
👉 DNS 延遲是 Request Lifecycle 的第一個不可控因素
2️⃣ TCP / TLS 建立
TCP 三向交握
HTTPS 還要 TLS 握手
是否有 Connection Reuse（Keep-Alive）差很多
👉 每一次新連線，都是昂貴操作
三、進入系統邊界：Load Balancer 與 Gateway
3️⃣ Load Balancer
決定這個請求要被送到哪一台機器
可能涉及：
Round-robin
Least connection
Health check 狀態
👉 Load Balancer 是第一個「放大或吸收流量衝擊」的地方
4️⃣ API Gateway / Reverse Proxy
在這一層，請求通常會被：
驗證（Auth / JWT）
限流（Rate Limit）
重寫路徑（Routing）
記錄 Log
👉 這裡不是轉發器，是政策執行層
四、進入服務內部：真正危險的地方
5️⃣ Thread / Event Loop
請求進到應用程式後，會佔用：
一個 Thread（同步模型）
或一段 Event Loop（非同步模型）
如果這裡卡住：
新請求進不來
舊請求出不去
👉 Thread / Event Loop 是系統的呼吸系統
6️⃣ Business Logic
這裡是大家最熟的地方：
驗證參數
執行邏輯
組合資料
但真正的風險不是邏輯錯，而是：
邏輯裡面呼叫了誰？
五、請求擴散：Fan-out 的開始
7️⃣ 呼叫其他服務（Sync Call）
一個 Request 很可能會：
呼叫 User Service
呼叫 Order Service
呼叫 Pricing Service
這稱為 Request Fan-out
👉 Fan-out 會讓延遲與失敗機率呈倍數成長
8️⃣ Cache / Database Access
每一次：
Cache Miss
DB Query
Index Scan
都會讓 Request 停下來「等」
👉 系統慢，通常不是在算，而是在等
六、錯誤處理：決定系統能不能活下來
9️⃣ Timeout
Timeout 不是為了「避免慢」
而是為了：
限制一個 Request 能傷害系統多久
沒有 Timeout：
Request 永遠卡住
Thread 永遠被佔用
🔟 Retry
Retry 看似保險，實際上很危險：
一個失敗 → 變成三個請求
流量放大
雪崩開始
👉 Retry 必須搭配 Backoff 與上限
七、回應階段：系統已經付出成本了
1️⃣1️⃣ Response 組裝
序列化 JSON
壓縮
設定 Header
1️⃣2️⃣ 回傳給 Client
Response 返回：
經過 Gateway
經過 Load Balancer
經過網路
👉 使用者看到的「慢」，是整條路徑的總和
八、為什麼理解 Request Lifecycle 這麼重要？
因為它會直接影響你做的每一個架構決策：
是否該同步呼叫？
Cache 要放在哪？
Timeout 設多長？
為什麼多加一個服務，穩定性反而下降？
為什麼 Queue 能救系統？
為什麼 Observability 是必須的？
所有 System Design 問題，幾乎都能追溯回 Request Lifecycle。
九、一個成熟系統的特徵
不是：
功能很多
技術很新
而是：
每一個 Request，都被清楚限制、觀察、保護
你不需要控制 Request 做什麼，
你需要控制的是：
它可以佔用多少資源
它可以活多久
它失敗時會不會拖垮別人
結語
HTTP Request 不是資料包，
它是系統中的生命體。
它會出生、擴散、等待、失敗、回收。
當你能清楚畫出一個 Request 的完整生命週期，
你才真正開始「設計系統」，而不只是「寫程式」。