2026年11月6日，掘金出現一篇長文，拆解「公車App上那句還有2站、約5分鐘是怎麼實現的」。這其實是後端工程師面試常見的場景設計題，作者從GPS漂移、訊息亂序、熱點讀取一路講到ETA不準的原因。文章本身是技術內容，但背後有兩件和你我有關的事：一是等公車時那份「數字到底準不準」的焦慮，二是寫系統的人熬夜看這種長文時的身體。
先說結論：那個「約5分鐘」本來就不是承諾
很多人以為App顯示的時間是車上GPS直接回報的倒數，其實照這篇文章的說法，那是一連串估算的結果。車機每3到10秒回報一次位置，資料先經過訊息佇列（可以想成資料的等候排隊機制）削峯，再由串流運算引擎清洗、把位置「貼回」地圖路線上，最後才算出預估到站時間。文章給出的目標是誤差控制在1到2分鐘內。
這意味著什麼？意味著你看到「約5分鐘」結果車遲到3分鐘，未必是App壞了。GPS在城市裡本來就會漂移，高架橋、隧道、密集大樓都會讓定位跳來跳去，系統得先判斷哪些資料不可信。知道這一點，你就可以少一點「到底要不要跑過去」的糾結：時間很短時，把它當參考值，提早一點到站牌，是比較安心的做法。
這篇文章也提醒我們怎麼讀技術文的數字
文中一個值得欣賞的地方，是作者堅持「先量化，再設計」：不先估好每秒寫入多少筆、讀取多少次，任何架構圖都是空談。以一個一線城市3萬輛公車估算，寫入約每秒3000筆，早晚高峯讀取可以衝到每秒上萬次查詢，一年累積的歷史軌跡資料以千億筆計。
這種讀法其實也適用於你平常看到的健康資訊。看到任何「研究顯示」「數據證明」時，先問：樣本多少？時間多長？誰做的？數字有沒有被拿來當聳動標題？公車預估可以容許誤差，因為它不會害死人；但健康建議如果來源不明，寧可先保留態度，這也是我們先前在Steam Linux 佔比的統計讀法一文裡提過的原則：看懂數字怎麼來，比記住數字本身重要。
看完技術長文，你的眼睛和脖子呢
這篇文章作者自己寫了「建議先收藏再細看」，因為全文超過40分鐘閱讀量。如果你是工程師，或是正在準備面試的人，這種文常常一追就追到半夜，一輪接一輪地查資料、翻文件。這裡有幾個可以馬上用的小動作。
看長文時，每30分鐘左右讓眼睛離開螢幕，看向6公尺外的東西20秒，這是眼科常見的放鬆建議，成本很低。坐姿上，螢幕上緣大概與視線齊平，脖子比較不用長時間前傾。如果你最近正在為面試或交付熬夜惡補系統設計，我們在App 架構演進長文與工程師身體照顧裡整理過更具體的眼睛、肩頸與作息做法，可以直接沿用。
還有一件小事：這類文章常附「完整程式碼」，看不懂全部也沒關係。作者自己都強調邊界要先對齊、不做的功能要主動說清楚。學習也一樣，一次拆懂一小段，比硬啃全文然後放棄，對你的學習情緒和睡眠都更友善。
回到等車的你
下次在站牌前盯著手機看那個「約5分鐘」，你已經知道它背後是一條每秒處理數千筆位置資料的管線，容忍著GPS漂移和路況變化。它可以不完美，但它不是隨便唬你的數字。
如果App顯示的時間反覆跳動、突然從5分鐘變成11分鐘，通常代表那班車的回報資料正在被重新估算，多留點緩衝時間就好。真的趕時間，提早出門永遠是最可靠的演算法。