医療機関のLINE予約システム事例｜並行制御、リアルタイム同期、および130+のテスト

問題の背景

予約システムの最も危険な点は、画面が見にくいことではなく、データベースでの競合です。2人の患者が同じ秒に同じ時間帯を予約しようとしたり、医療機関が一時的に休診になったにもかかわらず、患者側で古い時間帯が表示されたり、受付で予約ルールが更新されたにもかかわらず、LINE側で予約が許可されたりする状況です。これらの状況は、デモンストレーションでは発生しませんが、実際のトラフィック下では必ず発生します。このプロジェクトの核心は、「画面上では予約可能」と「データベース上で実際に予約」を2つの異なる事柄として扱います。また、バックエンドでのすべての変更が、患者側にもリアルタイムで反映されるようにします。

実装方法

• —データベースロックとトランザクション処理を同時に利用した予約：予約時にトランザクション内で時間帯を再検索しロックすることで、2人が同時に同じ時間帯を予約した場合、最初にロックを取得した方のみが予約成立となり、もう一方には明確なエラーメッセージが表示されます。
• —予約の信頼性：画面に表示される予約可能な時間帯はあくまで参考であり、予約が成立するための唯一の基準は、バックエンドでの取引時に再度確認することです。具体的には、時間帯が利用可能かどうか、患者が規則に準拠しているかどうか、既存の予約との競合がないかなどをサーバー側で再確認します。
• —Supabase Realtime による同期：診療所の休診、時間帯の調整、規則の変更時に、変更内容をリアルタイムで患者のインターフェースに送信し、情報のずれを短縮します。ただし、送信後もバックエンドでの確認が優先され、Realtime はユーザーエクスペリエンスを担当し、正確性を保証するものではありません。
• —例外的な状況をエンドツーエンドのテストとして記述：同時に予約を申し込む、予約後に直ちにキャンセルする、診療所の休診、規則変更後の再確認、接続が中断された後に再送信するなど、繰り返し実行可能なテストを作成し、変更ごとにまとめて検証を行います。

Falcon の実際の責任範囲

• LINE LIFF を利用した患者予約フロー
• 診療所の時間帯と予約管理後台
• Supabase Realtimeによるリアルタイム同期
• データベースの同時実行制御とエンドツーエンドのテスト

LINE を利用した予約と同時実行制御フロー

1. 01患者が LINE から LIFF 予約インターフェースを開き、利用可能な時間帯を読み込みます。このリストは画面上の参考であり、最終的な基準ではありません。
2. 02予約を送信する際、バックエンドで時間帯の利用可能性、予約規則、時間帯の競合などを再確認し、すべてを満たす場合にのみ予約が確定されます。
3. 032 人が同時に同じ時間帯を予約する場合、データベースのトランザクションによってどちらが成功するかを決定します。失敗した側には明確なメッセージが送信され、最新の利用可能な時間帯が再読み込みされます。
4. 04Realtime により、時間帯の変更とバックエンドの変更が患者と診療所の管理インターフェースの両方に同期されます。両者は同じ状態を表示します。

制限、失敗、および代替手段

• —複数の人が同時に同じ時間帯を予約する場合、バックエンドのトランザクション結果によってどちらが成功するかを決定します。失敗した側は、再度選択する必要があります。「先着順」という前提は成り立ちません。
• —リアルタイム接続が中断された場合、「予約完了」と仮定することはできません。画面には、バックエンドの正式な状態を確認してから結果を表示する必要があります。
• —規則の変更の効果は、サーバー側の時間に基づいて適用されます。患者側の画面が更新されていない場合、予約送信時にバックエンドによって拒否されます。
• —匿名事例では、患者、診療所、予約数、医療情報などを公開せず、医療または運営の成果を主張しません。

証拠の検証方法

• ✓130+ のエンドツーエンドテストでカバーされている状況のカテゴリ：通常の予約とキャンセル、同時時間帯での競合、診療所の時間帯の変更と休診、規則変更後の予約確認、接続中断と再送信。
• ✓テストの数字は、既公開されている事例の数を示しており、欠陥がないことを意味するものではありません。
• ✓データベースのロック、トランザクション、Realtime は、システム設計を指しており、運用上の約束を意味するものではありません。
• ✓顧客名、患者データ、予約数、運用指標などは公開されていません。

公開可能な測定値と能力