诊所 LINE 预约系统案例｜并发控制、即时同步与 130+ 测试

问题背景

预约系统最危险的不是画面不好看，而是资料层的竞态：两位病患在同一秒送出同一时段、诊所临时停诊但病患端还看得到旧时段、柜台更新了预约规则但 LINE 端还在放行。这些情境在展示时不会出现，在真实流量下一定会出现。这个案子的核心，是把「画面上看起来可以约」与「数据库里真的约到了」当成两件事分开处理，并让后台每一笔异动即时反映到病患端。

实践方式

• —以数据库锁定与交易处理同时预约：建立预约时在交易内重新查询并锁定该时段，两人同时送出时只有先取得锁的一方成立，另一方收到明确的失败消息，不会出现两人都显示成功的假象。
• —不信任前端状态：画面上的可预约时段只是参考，预约成立的唯一依据是后端交易当下的重新检查——时段是否仍开放、病患是否符合规则、是否与既有预约冲突，全部在服务器端重查一次。
• —使用 Supabase Realtime 同步：后台停诊、调整时段或修改规则时，变更即时推送到开启中的病患介面，缩短资讯落差；但送出后仍以后端检查为准，Realtime 负责体验，不负责正确性。
• —把例外情境写成端对端测试：同时抢约、预约后立即取消、后台临时停诊、规则变更后的重新检查、连线中断后重送，都做成可重复执行的测试，每次修改都能整批重跑验证。

隼讯实际负责范围

• LINE LIFF 病患预约流程
• 诊所时段与预约管理后台
• Supabase Realtime 即时同步
• 数据库并发控制与端对端测试

LINE 预约与并发控制流程

1. 01病患由 LINE 开启 LIFF 预约介面，载入当下可用时段；这份清单只是画面参考，不是最终依据。
2. 02送出预约时，后端在同一笔交易内重新检查时段开放状态、预约规则与时段冲突，全部通过才写入。
3. 03两人同时送出同一时段时，由数据库交易决定成功者；失败端收到明确消息，并重新载入最新的可用时段。
4. 04Realtime 将时段变化与后台异动同步到病患端与诊所管理介面，双方看到同一份状态。

限制、失败降级与替代方式

• —多人同时选择同一时段时，由后端交易结果决定成功者，失败端必须重新选择，不做「先到画面先得」的假设。
• —即时连线中断时不能假设预约成功，画面需重新查询后端正式状态后才显示结果。
• —后台规则异动的生效时间以服务器端为准，病患端画面若尚未更新，送出时仍会被后端检查拦下。
• —匿名案例不公开病患、诊所、预约量与医疗资讯，也不宣称医疗或运营成效。

证据如何核对

• ✓130+ 端对端测试涵盖的情境类别：正常预约与取消、同时段并发抢约、后台时段异动与临时停诊、规则变更后的预约检查、连线中断与重送。
• ✓测试数字代表既有公开作品纪录中的案例数，不代表零缺陷。
• ✓数据库锁定、交易与 Realtime 描述的是系统设计，不代表任何运营承诺。
• ✓客户名称、病患资料、预约量与运营指标均未公开。

可公开的量测与能力