Dienstag, 10 Uhr: Im fiktiven Werkstattbeispiel ist noch ein Platz frei. Zwei Personen öffnen die Terminseite und senden ihre Buchung fast gleichzeitig ab. Beide haben eine korrekte Verfügbarkeit gesehen. Trotzdem darf am Ende nur eine den Platz erhalten.

Der Server muss beim Speichern entscheiden, welche Buchung den Platz erhält. Kläre deshalb im Briefing, ob deine Website einen Wunschtermin übermittelt oder selbst einen Platz reserviert.

Was bedeutet der Button „Termin anfragen“?

Bei einer Anfrage meldet die Website einen Wunsch an deinen Betrieb. Du prüfst ihn und bestätigst anschließend. Das Formular muss dazu noch keine vollständige Verfügbarkeitsverwaltung besitzen. Die Bestätigung nach dem Absenden sollte aber genau diesen Stand erklären: Die Anfrage ist eingegangen; ein Termin ist noch nicht zugesagt.

Bei einer sofortigen Buchung muss das System dagegen selbst prüfen, ob der Platz noch frei ist. Die Anzeige im Browser kann bis zum Absenden veraltet sein. MDN erläutert, warum eine Prüfung im Browser die serverseitige Validierung nicht ersetzt.

Für eine Hundeschule ist außerdem zu unterscheiden, was gebucht wird. Ein Einzeltraining belegt eine bestimmte Trainerin und einen Zeitraum. Ein Gruppenkurs hat eine Teilnehmergrenze. Ein aus mehreren Terminen bestehender Kurs bringt weitere Regeln mit. Das sind verschiedene Datenmodelle, auch wenn die Oberfläche überall wie ein Kalender aussieht.

Verfügbarkeit entsteht aus Regeln

Beschreibe zunächst Ressource und Zeitraster. Bei einer Vermietung etwa ein konkret identifizierbares Fahrrad und feste halbe Tage. Halte dann fest, welche Sperren zusätzlich gelten: Wartung, Feiertage oder eine manuell eingetragene Reservierung.

Fiktives Werkstattbeispiel: Ein Termin dauert 60 Minuten. Danach bleiben 15 Minuten für Übergabe und Aufräumen frei. Der nächste angebotene Start liegt deshalb frühestens 75 Minuten nach dem vorherigen. Wird dieser Abstand nur in der Kalenderansicht versteckt, kann eine anders eingehende Buchung ihn umgehen. Die Regel gehört in die Prüfung beim Speichern.

Für gleichzeitige Buchungsversuche braucht die Speicherung eine technische Absicherung. Die PostgreSQL-Dokumentation beschreibt unter anderem Eindeutigkeits- und Ausschlussbedingungen. Welche davon passen, hängt von deinem Zeitmodell ab. Eine vorherige Abfrage „Ist noch frei?“ allein verhindert den gleichzeitigen Zugriff nicht.

Zwei Buchungsversuche für denselben Platz testen

Öffne denselben letzten Termin in zwei getrennten Sitzungen. Schicke beide Buchungsversuche nahezu gleichzeitig ab. Prüfe anschließend den gespeicherten Bestand und die Rückmeldungen. Eine Person erhält die Bestätigung, die andere eine verständliche Information samt neuer Auswahlmöglichkeit. Die Testumgebung darf dabei keine echten Kundennachrichten verschicken.

Auch Stornierungen brauchen Regeln. Ab wann ist die Ressource wieder frei? Was passiert, wenn jemand einen alten Bestätigungslink erneut öffnet? Und bleibt die Buchung gültig, falls die Benachrichtigung vorübergehend nicht versendet werden kann? Nachricht und gespeicherter Buchungsstatus sind getrennte Dinge.

Ein Formular- und Buchungsablauf bindet einen vorhandenen Endpunkt an. Die Leistung Buchungsanwendung entwickeln umfasst dagegen eine begrenzte eigene Verfügbarkeitslogik. Prüfe zuerst, ob ein vorhandenes Buchungssystem deine Regeln bereits abdeckt. Eine individuelle Anwendung lohnt sich erst, wenn die fehlenden Funktionen konkret benannt sind.