一般正常情況下，客戶端向系統請求資料的流程會長這樣子
客戶端 → Web Server → 系統 → 資料庫 → 系統 → Web Server → 客戶端- nginx確保客戶端的需求與資料能正確且安全的傳遞給系統伺服器
- 系統收到請求後，經過程式邏輯確認 要完成這個請求需要的資料有哪些，向資料庫發送query
- 資料庫收到query並執行，把檢索結果傳給系統
- 系統收到資料會把他們整理/運算/組合 成Web Server接收的形式，在傳給Web Server
- Web Server收到資料傳給客戶端瀏覽器渲染出來
想像一下，如果第4步驟中有高達300~500多行程式碼都再處理 整理/運算/組合，這些複雜的程式邏輯每次客戶端請求都要在run過一遍，結果不是客戶端等到天荒地老海枯石爛，就是系統直接罷工不錄了。
所以Cache的核心價值就出來了! 當客戶端第一次請求需要經過複雜程式邏輯才能跑出來的資料時，系統會如實地run過一遍上述的流程，然後在傳給Web Server之前把結果存在Cache中，並把這份暫存資料告訴Web Server，等到下次客戶端再次請求同樣的資料時，系統直接從Cache中拿給Web Server，直接省略和資料庫交流與複雜的程式邏輯運算。
客戶端 → Web Server → 系統 →|檢查Cache中是否有資料| 沒有 → 資料庫 → 系統 → Web Server → 客戶端
→|檢查Cache中是否有資料| 有 → Cache → Web Server → 客戶端Cache的使用時機
- 需要經過複雜計算才能得到資料
- 經常被讀取但很少被修改的資料，例如統計資料、社群媒體的貼文
實際應用
當客戶端想要讀取某位使用者當下的進度狀態資料，如進行中、通過、未通過、進度%數等等，而這些進度狀態的判別需要從資料庫中select 多個沒有直接關聯的table進行資料的交叉比對、運算處理後才能判斷狀態，在此情況下若未使用Cache，客戶端每查看一個人的進度，則系統就要運算一次，會造成使用者體驗大幅下降，對系統產生不信任感，更別提客戶端想要同時查看多位使用者的進度了。