Doppelbuchungen verhindern: warum Systeme versagen, und das Modell, das es nicht kann
Doppelbuchungen passieren fast nie, weil ein Kalender „einen Fehler gemacht hat“. Sie passieren, weil die Software prüfte, ob ein Termin frei war, und ihn reservierte, als zwei getrennte Schritte mit einer Lücke dazwischen – und eine zweite Kundin durch die Lücke schlüpfte. Schließen Sie diese Lücke, und der Rest des Kalenders kann so einfach oder aufwendig sein, wie Sie wollen. Lassen Sie sie offen, und kein noch so poliertes Buchungs-Widget verhindert, dass gelegentlich zwei Personen auf demselben Stuhl landen.
Wo die Lücke wirklich entsteht
Die übliche Abfolge hinter fast jeder Buchung: prüfen „ist dieser Termin noch frei?“, „ja“ als Antwort bekommen, dann die Buchung schreiben. Ein Lesen, dann ein Schreiben – und dazwischen, wie kurz auch immer, ein Zeitfenster. Eine zweite Anfrage, die denselben Termin während dieses Fensters prüft, sieht ebenfalls „ja, noch frei“. Beide glauben nun, einen freien Termin zu buchen, weil er es in dem Moment, in dem jede von ihnen hinsah, tatsächlich war.
Sie können nicht durch das Durchklicken einer Demo an einem ruhigen Dienstagnachmittag erkennen, ob Prüfung und Schreibvorgang darunter sicher gekoppelt oder gefährlich getrennt sind – der Kalender sieht so oder so identisch aus.
Warum "einfach einen schöneren Kalender" das nicht löst
Viel Buchungssoftware ist unter dem Widget ein generischer Formular-Baukasten, der nie dafür ausgelegt war, dass zwei Personen gleichzeitig dasselbe begrenzte Gut beanspruchen. Die Terminauswahl kann flüssig sein, die Verfügbarkeit live wirken, der Bestätigungsbildschirm sauber – und das Backend prüft trotzdem mit einem Lesevorgang und schreibt mit einem separaten, späteren Schreibvorgang. Echter, gleichzeitiger Traffic findet die Naht.
Das Modell, das die Lücke wirklich schließt
Behandeln Sie „prüfen“ und „reservieren“ nicht länger als zwei Vorgänge: Führen Sie die Verfügbarkeitsprüfung erneut aus und schreiben Sie die Buchung innerhalb einer einzigen Datenbanktransaktion, die die Zeilen für diesen Termin sperrt. Welche Anfrage auch zuerst ankommt, sie schließt ihre Prüfung-und-Schreiben ununterbrochen ab; die zweite wartet, bis sie an der Reihe ist, und prüft dann erneut gegen die neue Realität. Es bleibt kein Zeitfenster, in dem auf veralteten „noch verfügbar“-Informationen gehandelt werden könnte – die Datenbank erzwingt die Reihenfolge, statt dass Anwendungscode nur hofft, dass nichts kollidiert.
Was wirklich passiert, wenn zwei Personen gleichzeitig auf „buchen“ klicken
1
Beide Anfragen treffen kurz nacheinander ein
2
Eine Anfrage erhält die Sperre zuerst
3
Die erste Anfrage prüft neu und schreibt — beides zusammen
4
Die zweite Anfrage prüft erneut gegen die neue Realität
5
Der zweite Kunde erfährt es sofort
Wie Olmira das löst
Die Buchungslogik von Olmira führt die erneute Verfügbarkeitsprüfung und das Schreiben der Buchung als einen einzigen Schritt aus, innerhalb einer einzigen gesperrten Datenbanktransaktion — wenn also zwei Kunden gleichzeitig denselben Termin ansteuern, wird eine Buchung festgeschrieben, und der anderen wird mitgeteilt, noch bevor Geld fließt, dass der Termin gerade weg ist. Dieselbe Sperre umfasst auch die zugrunde liegende Ressource, nicht nur den verkauften Service, sodass zwei verschiedene Services, die sich einen Raum oder eine Person aus dem Team teilen, sie ebenfalls nicht unbemerkt doppelt belegen können. Ein separater, kleinerer Schutz fängt das häufigere Missgeschick ab — derselbe Kunde klickt zweimal auf „buchen“ — und bittet ihn um eine Bestätigung, statt still zwei Termine anzulegen. Wie das zusammenspielt, sehen Sie auf der Buchungsseite.
Verwandte Leitfäden
No-Shows: Was die Zahl wirklich bewegt
Nein – hoher Traffic sorgt nur dafür, dass es früher auffällt. Die zugrunde liegende Lücke besteht in dem Moment, in dem mehr als eine Anfrage für denselben Slot unterwegs sein kann, und das gilt auch auf einer ruhigen Seite; bei einem Betrieb mit wenig Traffic können schlicht Monate zwischen den seltenen Momenten liegen, in denen zwei Personen gleichzeitig klicken. Es ist eine Eigenschaft des Entwurfs und keine Funktion davon, wie viel bei Ihnen los ist.
Nein. Der Kalender ist das, was die Kundschaft sieht; der Teil, der Doppelbuchungen verhindert, passiert vollständig auf dem Server, unsichtbar, genau in dem Moment, in dem eine Buchung geschrieben wird. Eine schicke Kalenderoberfläche sagt Ihnen nichts darüber, was darunter geschieht, wenn zwei Menschen in derselben Sekunde auf dasselbe Zeitfenster klicken.
Sie sollten sofort erfahren – bevor irgendeine Zahlung eingezogen wird –, dass das Zeitfenster gerade weg ist, und die nächste echte Option angezeigt bekommen. Der Fehlerfall, über den man sich Sorgen machen sollte, ist der umgekehrte: ein System, das beide Buchungen durchlässt und den Konflikt erst später sichtbar macht, meist dann, wenn jemand vor der Tür steht.
Derselbe Mechanismus gilt überall dort, wo etwas Gemeinsames und Begrenztes gebucht wird – ein Tisch, ein Raum, ein Gerät, ein Lieferfenster. Die Lösung hat jedes Mal dieselbe Form: die tatsächlich knappe Ressource genau im Moment der Zusage sperren und erneut prüfen, nicht einen Moment früher.
Ja, in bestimmten Branchen — Fluggesellschaften überbuchen seit jeher Sitzplätze gegen eine prognostizierte No-Show-Quote, als bewusste, durchgerechnete unternehmerische Entscheidung mit einer daran gekoppelten Entschädigungsregelung. Das ist etwas anderes als die versehentliche Variante, um die es in diesem Leitfaden geht, bei der es niemand beabsichtigt hat und niemand froh ist, sie zu entdecken.