診所 LINE 預約系統案例｜併發控制、即時同步與 130+ 測試

問題背景

預約系統最危險的不是畫面不好看，而是資料層的競態：兩位病患在同一秒送出同一時段、診所臨時停診但病患端還看得到舊時段、櫃檯更新了預約規則但 LINE 端還在放行。這些情境在展示時不會出現，在真實流量下一定會出現。這個案子的核心，是把「畫面上看起來可以約」與「資料庫裡真的約到了」當成兩件事分開處理，並讓後台每一筆異動即時反映到病患端。

實作方式

• —以資料庫鎖定與交易處理同時預約：建立預約時在交易內重新查詢並鎖定該時段，兩人同時送出時只有先取得鎖的一方成立，另一方收到明確的失敗訊息，不會出現兩人都顯示成功的假象。
• —不信任前端狀態：畫面上的可預約時段只是參考，預約成立的唯一依據是後端交易當下的重新檢查——時段是否仍開放、病患是否符合規則、是否與既有預約衝突，全部在伺服器端重查一次。
• —使用 Supabase Realtime 同步：後台停診、調整時段或修改規則時，變更即時推送到開啟中的病患介面，縮短資訊落差；但送出後仍以後端檢查為準，Realtime 負責體驗，不負責正確性。
• —把例外情境寫成端對端測試：同時搶約、預約後立即取消、後台臨時停診、規則變更後的重新檢查、連線中斷後重送，都做成可重複執行的測試，每次修改都能整批重跑驗證。

隼訊實際負責範圍

• LINE LIFF 病患預約流程
• 診所時段與預約管理後台
• Supabase Realtime 即時同步
• 資料庫併發控制與端對端測試

LINE 預約與併發控制流程

1. 01病患由 LINE 開啟 LIFF 預約介面，載入當下可用時段；這份清單只是畫面參考，不是最終依據。
2. 02送出預約時，後端在同一筆交易內重新檢查時段開放狀態、預約規則與時段衝突，全部通過才寫入。
3. 03兩人同時送出同一時段時，由資料庫交易決定成功者；失敗端收到明確訊息，並重新載入最新的可用時段。
4. 04Realtime 將時段變化與後台異動同步到病患端與診所管理介面，雙方看到同一份狀態。

限制、失敗降級與替代方式

• —多人同時選擇同一時段時，由後端交易結果決定成功者，失敗端必須重新選擇，不做「先到畫面先得」的假設。
• —即時連線中斷時不能假設預約成功，畫面需重新查詢後端正式狀態後才顯示結果。
• —後台規則異動的生效時間以伺服器端為準，病患端畫面若尚未更新，送出時仍會被後端檢查攔下。
• —匿名案例不公開病患、診所、預約量與醫療資訊，也不宣稱醫療或營運成效。

證據如何核對

• ✓130+ 端對端測試涵蓋的情境類別：正常預約與取消、同時段併發搶約、後台時段異動與臨時停診、規則變更後的預約檢查、連線中斷與重送。
• ✓測試數字代表既有公開作品紀錄中的案例數，不代表零缺陷。
• ✓資料庫鎖定、交易與 Realtime 描述的是系統設計，不代表任何營運承諾。
• ✓客戶名稱、病患資料、預約量與營運指標均未公開。

可公開的量測與能力