Fallbeispiel für ein LINE-Buchungssystem für eine Arztpraxis: Nebenläufige Steuerung, Echtzeit-Synchronisation und 130+-Tests

Hintergrund der Probleme

Das größte Risiko bei einem Buchungssystem ist nicht die schlechte Optik, sondern der Wettlauf in der Datenebene: Zwei Patienten senden gleichzeitig eine Anfrage für denselben Zeitraum, die Praxis schließt vorübergehend, aber der Patient kann immer noch den alten Zeitraum sehen, oder die Rezeption aktualisiert die Buchungsregeln, aber die LINE-Seite erlaubt die Buchung weiter. Diese Szenarien treten nicht auf, sondern treten in realen Bedingungen auf. Der Kern dieses Falls besteht darin, die „Anzeige, dass eine Buchung möglich ist“ und die „tatsächliche Buchung in der Datenbank“ als zwei separate Vorgänge zu behandeln und sicherzustellen, dass jede Änderung im Backend in Echtzeit auf die Patientenseite übertragen wird.

Methodische Vorgehensweise

• —Reservierung mit Datenbank-Sperrung und gleichzeitiger Transaktionsverarbeitung: Bei der Reservierung wird der entsprechende Zeitraum innerhalb der Transaktion gesperrt und neu abgefragt. Wenn beide Parteien gleichzeitig versuchen, die Reservierung zu tätigen, wird nur die erste erfolgreiche Reservierung bestätigt, während die andere Partei eine klare Fehlermeldung erhält und keine falsche Erfolgsmeldung erhält, dass beide erfolgreich waren.
• —Nicht-Vertrauens-Frontend-Status: Die angezeigten verfügbaren Zeitfenster sind nur eine Referenz. Die Buchung wird nur durch eine erneute Überprüfung auf dem Backend bestätigt – sind die Zeitfenster noch verfügbar, erfüllt der Patient die Regeln, gibt es Konflikte mit bestehenden Buchungen? All dies wird auf dem Server überprüft.
• —Verwendung von Supabase Realtime für die Synchronisierung: Wenn das Praxis geschlossen wird, die Zeiten geändert oder die Regeln angepasst werden, werden die Änderungen sofort an die offenen Patientenschnittstellen gesendet, um Informationslücken zu vermeiden. Nach dem Senden wird jedoch weiterhin die Überprüfung durch das Backend als maßgeblich betrachtet. Realtime ist für die Benutzererfahrung verantwortlich, nicht für die Korrektheit.
• —Ausnahmen als End-to-End-Tests implementieren: Gleichzeitige Buchungsversuche, sofortige Stornierung nach der Buchung, temporäres Schließen der Praxis, erneute Überprüfung nach Änderungen der Regeln und erneutes Senden nach Verbindungsabbrüchen sollten als wiederholbare Tests implementiert werden, sodass jede Änderung vollständig überprüft werden kann.

Verantwortungsbereich von Falcon

• Patienten-Buchungsprozess mit LINE LIFF
• Praxis-Zeitplan und Buchungsverwaltung-Backend
• Supabase Realtime für Echtzeit-Synchronisation
• Datenbank-Concurrency-Kontrolle und End-to-End-Tests

Buchungsprozess mit LINE und Concurrency-Kontrolle

1. 01Der Patient öffnet die LINE LIFF-Buchungsseite und lädt die verfügbaren Zeitfenster zum aktuellen Zeitpunkt. Diese Liste ist nur eine Referenz und kein endgültiger Anweisungsgeber.
2. 02Beim Absenden einer Buchung wird die Verfügbarkeit der Zeitfenster, die Buchungsregeln und mögliche Konflikte auf dem Backend erneut überprüft. Nur wenn alle Bedingungen erfüllt sind, wird die Buchung gespeichert.
3. 03Wenn zwei Personen gleichzeitig dasselbe Zeitfenster buchen, bestimmt die Datenbanktransaktion, wer erfolgreich ist. Das fehlerhafte System erhält eine klare Meldung und lädt die neuesten verfügbaren Zeitfenster neu.
4. 04Realtime synchronisiert Änderungen der Zeitfenster und Änderungen im Backend mit der Patientenschnittstelle und der Praxis-Verwaltungs-Schnittstelle, sodass beide die gleiche Statusinformation sehen.

Einschränkungen, Fehlerbehandlung und Alternativen

• —Wenn mehrere Personen gleichzeitig dasselbe Zeitfenster buchen, bestimmt das Ergebnis der Backend-Transaktion, wer erfolgreich ist. Das fehlerhafte System muss erneut auswählen und darf nicht von der Annahme ausgehen, dass "wer zuerst kommt, mahlt zuerst".
• —Bei sofortigem Verbindungsabbruch darf nicht davon ausgegangen werden, dass die Buchung erfolgreich war. Das Ergebnis wird erst nach erneuter Überprüfung des Backend-Status auf dem Bildschirm angezeigt.
• —Die Gültigkeit von Änderungen der Regeln wird auf dem Server-Ende festgelegt. Wenn die Patientenschnittstelle noch nicht aktualisiert wurde, wird die Buchung weiterhin vom Backend abgelehnt.
• —Anonyme Fallstudien veröffentlichen keine Informationen über Patienten, Praxis, Buchungszahlen und medizinische Daten und behaupten auch keine medizinischen oder betrieblichen Ergebnisse.

Wie Beweise überprüft werden

• ✓130+ End-to-End-Tests decken folgende Szenarien ab: Normale Buchung und Stornierung, gleichzeitige Buchungsversuche, Änderungen der Zeiten und temporäres Schließen der Praxis, Buchungsüberprüfung nach Änderungen der Regeln, Verbindungsabbrüche und erneutes Senden.
• ✓Die Testzahlen entsprechen der Anzahl der Fälle in öffentlich dokumentierten Projekten und stellen keine Fehlerfreiheit dar.
• ✓Datenbank-Lock, Transaktionen und Realtime beschreiben Systemdesign, nicht betriebliche Zusagen.
• ✓Kundenname, Patientendaten, Buchungszahlen und betriebliche Kennzahlen werden nicht veröffentlicht.

Verfügbare Messwerte und Fähigkeiten