前言
今天要把三支 API（/bus/routes、/bus/stops、/bus/eta）排成一條「每天都看得懂」的資料路線。平常怎麼查、什麼時候要存、多久要重抓、尖峰時段要不要換做法，今天一起說清楚。
一、我們手上的三種資料
1.固定的（路線、站點）
描述有哪些路線、每條路線經過哪些站，變化不大，可以一段時間抓一次。
2.即時的（到站時間）
描述現在還要等多久、是不是末班或暫停，變化很快。
3.我們自己產的（查詢紀錄、排程存檔）
為了好維護、好展示、做報表自己留下來的資料，例如今天幾點抓過。
二、平常版資料流（一般時段）
這版是在人不多、不是上下班、不是要 demo 給一大群人看的情況下用的。
•一開始要畫面 → 先抓固定資料：先打 /bus/routes 拿路線，再打 /bus/stops 拿站點，抓到之後可以暫存起來。
•真的要顯示「幾分鐘到」時 → 再打 /bus/eta，帶 routeId + stopId，回來的資料照我們 Day 13 的規則檢查一下，然後顯示。
•顯示完 → 存一份今天的：記下查了哪一站、幾點查到、系統回幾秒、updateTime 是多少，之後做報表用。
•隔一段時間再更新固定資料：routes、stops 不用每次都抓，可以 1 小時或半天抓一次。
一句話：固定的先抓一次 → 即時的要看才抓 → 抓完記一筆 → 隔一段時間重抓固定的。
三、尖峰版資料流
尖峰時段的重點是先抓一次，大家分著看，避免很多人一起打來源 API 把後端塞爆。
•由系統自己先抓：例如每 30 秒抓一次 /bus/eta，一次抓多站或常用路線，放到快取或暫存。
•使用者要看的時候 → 不要再打來源：直接讀剛剛快取好的那份，畫面標「資料更新於 HH:MM:SS」。
•真的要最新 → 才打來源：做一顆「重新整理到站時間」的按鈕，按了才打真正的來源。
•一樣要存一筆：尖峰時段也要記錄失敗與延遲，之後 Day 21 看指標才看的出來。
一句話：尖峰時段先由系統抓 → 畫面讀快取 → 真的要最新再打 → 每次抓都要記錄。
四、為什麼要分「平常版」跟「尖峰版」
我在Day 12 提過查太頻會被限速，Day 4 也說要讓使用者看到多久前更」。如果所有情況都讓使用者直接打來源，一到早上或放學時間就可能被回 429。分成兩版的好處是：排程可以走尖峰版、報告能說有考慮尖峰流量、前端比較好控制查詢節奏。