延續昨天的震撼教育，在實作之前，我們必須先釐清「真實世界的系統」到底長什麼樣子。

以前自己寫些小專案時，只要資料庫寫得進去、畫面出得來就好。但在真實的商業環境裡，不同類型的服務面臨著截然不同的極端挑戰。我們用幾個生活化的例子來堆疊出這些情境：

1. 演唱會訂票系統（瞬間的流量海嘯）
平時可能沒什麼人在用，但只要一到中午 12 點開賣，瞬間會有幾十萬人同時點擊「確認購票」。這時候系統面臨的是極端殘酷的「高併發寫入」。如果底層連線沒有處理好，伺服器的連線池瞬間就會被榨乾，導致大部分的人看到畫面轉圈圈，最後跳出 502 Bad Gateway ! 只有跳出錯誤還好，但如果有些人正在訂位的過程中被中斷，下次重整就沒有位子了，又或是刷卡刷到一半呢? 一旦被中斷如果刷成功但是系統沒紀錄怎麼辦? 所以面對突發的流量處理或是錯誤處理的機制是非常重要的

2. 串流影音與社群平台（細緻的錯誤處理與低延遲）
當你在搭捷運或高鐵時，一邊滑著社群平台，一邊上傳剛拍好的高畫質影片。這時網路會在 4G、5G 甚至斷訊之間不斷切換。系統不僅需要極低的延遲（Latency）來保證互動的順暢感，更需要極其細緻的錯誤處理（Error Handling）。如果使用者上傳到 99% 時網路斷了一秒，系統總不能叫他從 0% 重新上傳吧？同時，這些珍貴的使用者圖片和影音「絕對不能遺失」，公司必須要有完善的資料庫備份與狀態確認機制。

(圖片來源)

企業級「三高」的具體標準是什麼？

回到第一天有提到的三高資訊，這些名詞背後都有具體標準的數據：

• 高併發 (High Concurrency)：
  我們不看「總會員數」，而是看 QPS (Queries Per Second) 或 TPS (Transactions Per Second)。例如：系統能否在不引發執行緒飢餓 (Thread Starvation) 的情況下，穩定扛住每秒 10,000 次的 API 請求？
• 高效能 (High Performance)：
  我們不看「平均處理時間」，因為那會被極端值掩蓋。企業通常看 P99 Latency。意思是：系統必須保證 99% 的請求，都能在例如 200 毫秒（0.2秒）內處理完畢並回傳結果。
• 高可用 (High Availability, HA)：
  我們看的是 「幾個 9」。一般企業系統會追求「四個 9（99.99%）」，代表系統一年 365 天內，總共停機的時間不能超過 52.6 分鐘。這意味著當遇到硬體死機或網路中斷時，系統必須要有自動故障轉移（Failover）的能力，確保服務不中斷、資料零遺失。

設計一個系統的必備考量面向

當我們現在要設計一個系統時，我們必須像個決策者一樣，綜合評估考量以下面向：
1. 釐清功能性與非功能性需求

• 功能性需求 (Functional)： 系統「要做什麼」。例如：使用者可以透過 API 上傳圖片、查詢進度、刪除圖片。
• 非功能性需求 (Non-Functional)： 系統「做得多好」。也是最常被大家忽略的部分，這就是上述的三高指標、資料強一致性、安全性等。

2. 系統容量預估 (Capacity Planning)

• 流量評估： 預估 DAU (日活躍用戶) 是多少？尖峰時段的最大 QPS 是多少？
• 儲存與硬體： 每天預期新增多少檔案？平均檔案大小？需要多大的資料庫和 S3 空間？這決定了我們要開什麼等級的機器。

3. 基礎設施與架構選型

• 要自建地端機房 (On-premise) 還是上雲 (Cloud)？為了快速擴展並減少維運成本，現在多半選擇 AWS、GCP 等雲端服務。
• 架構上，我們的服務如果是 CPU 密集或 I/O 密集，該選擇哪種連線引擎？

4. 部署規劃與 CI/CD 自動化

• 我們需要自動化測試與 CI/CD 流水線（例如 GitHub Actions、Jenkins）。
  

5. 災難復原與備份策略 (Disaster Recovery)

• 資料多久備份一次？(RPO：可容忍的資料遺失量)。
• 系統掛掉後要多久內恢復？(RTO：可容忍的停機時間)。
• 當單機達到極限崩潰時，架構能不能迅速且無痛地水平擴展 (Scale-out)？

為什麼我們要在寫 Code 前想這麼多？

這是我在公司學到最痛的一課：「修改成本的指數型暴增」。

軟體工程有一個著名的法則：如果在需求與設計階段發現並修正一個架構缺陷，成本是1；如果在開發階段才改，成本是5倍；如果在測試階段發現，成本是 10 倍；如果等系統已經「上線到正式環境 (Production)」才爆炸，修正的成本和代價高達 100 倍！

(圖片來源)

這就是為什麼接下來的鐵人賽，我不急著帶大家馬上寫Code。要先清楚為什麼傳統連線會爆炸，設計好防呆機制，並規劃好壓力測試。了解每個決策背後的意義，才不會讓系統上線後成為那可怕的成本。

下一篇，我們就會先從底層連線機制開刀，探討為什麼「同步連線」會成為高併發情境下的最大瓶頸！我們明天見！