Doppelbuchungen verhindern: Warum die meisten Systeme eine Lücke haben

Das Problem in einem Satz

Ein Terminsystem prüft, ob eine Zeit frei ist, und speichert dann die Buchung. Das sind zwei Schritte. Fragen zwei Kunden im selben Moment dieselbe Zeit an, kann beiden „frei“ geantwortet werden, bevor einer von beiden gespeichert hat.

Der Ablauf, Schritt für Schritt:

1. Kundin A öffnet die Seite. System: Dienstag 10:00 ist frei.
2. Kunde B öffnet die Seite. System: Dienstag 10:00 ist frei.
3. A klickt „buchen“. System prüft: noch frei. Speichert.
4. B klickt „buchen“. System prüft – und die Prüfung lief los, bevor A gespeichert hatte. Speichert ebenfalls.
5. Zwei Kunden, ein Termin.

In der Softwareentwicklung heißt das Race Condition. Sie ist deshalb so tückisch, weil sie im Test nie auftritt: Beim Ausprobieren klickt man nacheinander. Sie tritt auf, wenn viele Menschen gleichzeitig buchen – nach einem Newsletter, einer neuen Immobilienanzeige, einem Beitrag, der gut läuft. Also genau dann, wenn es zählt.

Drei verbreitete Halblösungen

„Wir prüfen vor dem Speichern noch einmal“

Besser als nichts, schließt die Lücke aber nicht – sie wird nur schmaler. Zwischen der zweiten Prüfung und dem Speichern bleibt derselbe Spalt, nur eben Millisekunden statt Minuten. Bei wenigen Buchungen fällt das nie auf. Bei vielen schon.

„Wir reservieren den Termin für fünf Minuten“

Sinnvoll, damit niemand während des Ausfüllens den Termin verliert. Löst das Grundproblem aber nicht: Die Reservierung selbst wird ja auch geprüft und gespeichert – und hat damit dieselbe Lücke, nur eine Ebene tiefer.

„Wir sperren, solange gebucht wird“

Funktioniert, kostet aber Tempo: Alle anderen warten. Und wenn der Sperrmechanismus hängt – ein abgebrochener Vorgang, ein Neustart –, ist im schlimmsten Fall der ganze Kalender blockiert. Wer schon einmal nachts eine klemmende Sperre gelöst hat, baut das ungern.

Die tragfähige Lösung: die Datenbank entscheiden lassen

Statt zu prüfen und dann zu schreiben, schreibt man so, dass ein zweites Schreiben derselben Zeit unmöglich ist. Prüfung und Buchung fallen in einen einzigen, unteilbaren Vorgang zusammen – es gibt keine Lücke mehr, weil es keine zwei Schritte mehr gibt.

Technisch gibt es dafür zwei etablierte Wege:

• Ausschluss-Bedingung über Zeitbereiche. Manche Datenbanken können ausdrücken: „Keine zwei Einträge dürfen sich zeitlich überschneiden.“ Die Datenbank weist den zweiten Schreiber selbst ab.
• Zeitraster mit Eindeutigkeitsregel. Die Zeit wird in feste Schritte zerlegt – etwa fünf Minuten. Jede Buchung belegt einen Eintrag je Schritt, und eine Eindeutigkeitsregel verbietet zwei Einträge für denselben Schritt. Der zweite Schreiber läuft auf einen Fehler und wird sauber zurückgerollt.

Beide Verfahren haben dieselbe Eigenschaft: Die Garantie liegt in der Datenbank, nicht in der Reihenfolge, in der Anwendungscode zufällig ausgeführt wird. Wer die Regel umgehen will, müsste die Datenbank selbst ändern.

TerminKraft nutzt das zweite Verfahren. Jede Buchung belegt einen Eintrag je Fünf-Minuten-Schritt ihrer Sperrzone, geschützt durch eine Eindeutigkeitsregel. Zwanzig gleichzeitige Buchungsversuche auf denselben Termin ergeben genau eine Buchung – geprüft gegen die echte Datenbank, nicht gegen eine Nachbildung.

Der zweite Grund für Terminkollisionen: fehlende Puffer

Nicht jede Kollision ist eine Doppelbuchung. Häufiger ist der Fall, dass zwei Termine technisch nicht überlappen, praktisch aber trotzdem nicht zusammengehen: 10:00 bis 10:30 in Kaiserslautern und 10:30 bis 11:00 in Landstuhl.

Ein Puffer vor und nach dem Termin gehört deshalb zur Terminart, nicht zum guten Willen. Wichtig ist, dass er die Zeit tatsächlich sperrt und nicht nur als Hinweis angezeigt wird. Und dass Ihr Kunde ihn nicht sieht – er bucht 30 Minuten, auch wenn intern 90 blockiert sind.

So prüfen Sie ein System selbst

Zwei Browserfenster, dieselbe Buchungsseite, beide auf demselben Termin bis zum Absenden vorbereitet. Dann beide so schnell wie möglich absenden.

• Gut: Eine Buchung geht durch, die andere bekommt eine verständliche Meldung und aktualisierte freie Zeiten.
• Schlecht: Beide bekommen eine Bestätigung.
• Auch schlecht: Die zweite bekommt eine Fehlerseite ohne Erklärung. Der Konflikt wurde zwar erkannt, aber der Kunde bleibt ratlos zurück.