案例05｜Healthcare Monolith：多部門同時使用後，單體架構成為瓶頸

一、案例定位

本案例依原書第 4 章 Breaking Free from Monoliths 情境重組，並非原書正式案例研究。

理解為何 AI 系統進入多部門使用後，需要讓不同元件依各自 Demand 獨立擴充。

二、學習目標

說明 Monolithic Architecture 的擴充限制。
理解不同服務的 Peak Demand 可能出現在不同時間。
將 Scaling Unit 從整體系統改成獨立元件。

三、案例情境

某醫療機構的 Patient Documentation System 最初是一個單體應用，初期足以使用；當多個部門同時發送要求後，單體設計變成瓶頸，因為無法按各元件需求獨立 Scale。原書舉例，Document Processing Service 可能在 Business Hours 需要更多資源，而 Model Inference 可能在 Overnight Batch Processing 出現尖峰。

四、開始資料

元件／需求	可能 Peak 時段	架構要求
Document Processing	Business Hours	可獨立增加資源
Model Inference	Overnight Batch Processing	可依夜間負載獨立 Scale
Monolithic Application	所有元件綁在一起	難以只擴需要的部分

五、Excel／AI 分析方法

Excel 可按時段記錄各服務 Demand、CPU／GPU、Queue、Latency；AI 可協助分析不同元件的尖峰模式。原書沒有數值資源需求，不能自行填入容量。

六、計算結果

原書未提供具體時段流量或資源數值，因此本案例沒有可計算 Capacity 結果。

七、結果分析與管理解讀

獨立 Scaling 不只是技術潔癖，而是避免為一個元件的尖峰把整個系統一起擴充。不同負載模式需要不同資源策略。

八、AI 提問詞

請把我的 Monolithic AI System 拆成可獨立 Scale 的服務候選，並依實際監控資料比較各自 Peak Demand。若沒有 Capacity Data，請標示未知，不要估算。