slotline
Eine Plattform zur Ressourcenbuchung (Räume, Plätze, Ausrüstung) auf Spring Boot. Der Kern garantiert, dass ein Slot niemals doppelt gebucht wird - selbst bei hoher Parallelität.
Eine Plattform zur Reservierung von Ressourcen (Räume, Plätze, Ausrüstung) auf Spring Boot. Sie wirkt trivial, bis zwei Personen in derselben Millisekunde auf denselben Slot klicken. Der Kern garantiert, dass ein Termin nie doppelt gebucht wird, selbst bei hoher Nebenläufigkeit.
Einführung
Einen Termin zu buchen sieht aus wie das Einfügen einer Zeile, und viele Entwickler schreiben es genau so. Das Problem ist, dass die echte Schwierigkeit nicht im typischen Fall liegt, sondern in der einen Millisekunde, in der zwei Personen nach demselben freien Slot greifen. slotline ist um diese eine Millisekunde herum gebaut, nicht um das Buchungsformular.
Alles andere an der Plattform, die Ressourcen, der Kalender und die Ansichten, umschließt eine einzige Garantie: dass ein Slot genau einen Gewinner hat. Das entscheidet, ob das System ernst zu nehmen ist oder nur so aussieht, als funktioniere es bis zum ersten Andrang.
Die ganze Schwierigkeit steckt in einer Millisekunde
Eine naive Implementierung macht zwei Schritte: Sie prüft, ob der Slot frei ist, und schreibt ihn dann. Zwischen diesen Schritten gibt es eine Lücke, in der ein zweiter Nutzer denselben Slot als frei sehen kann. Beide bestehen die Prüfung, beide schreiben, und Sie haben zwei Buchungen für einen Termin, von denen niemand wusste, dass sie möglich sind.
slotline behandelt das als das Hauptproblem, das es zu lösen gilt, nicht als Randfall. Das Domänenmodell ist gerade deshalb klar, damit diese eine Garantie beim Lesen des Codes offensichtlich ist und nicht irgendwo in einer Service-Schicht vergraben.
Verfügbarkeit prüfen und die Buchung schreiben sind keine zwei getrennten Operationen. Wenn sie es sind, haben Sie ein Rennen. Die Garantie kommt von der Datenbank, über eine Unique-Bedingung auf Ressource plus Zeitfenster, nicht von einer Prüfung im Anwendungscode.
Die Unique-Bedingung verlagert die Entscheidung an den einzigen Ort, an dem Nebenläufigkeit wirklich serialisiert wird: die Datenbank-Engine. Es spielt keine Rolle, wie viele Nutzer gleichzeitig klicken, denn über den Gewinner entscheidet ein atomarer Schreibvorgang, und die Verlierer bekommen einen sauberen Konfliktfehler statt einer stillen Doppelbuchung.
Ein Test, der wirklich fehlschlagen kann
Es ist leicht, einen Test zu schreiben, der einmal bucht und prüft, dass es geklappt hat. Das beweist nichts, weil er die Bedingung, die halten soll, nie berührt. Der wertvolle Test feuert viele Threads gleichzeitig auf denselben Slot und stellt sicher, dass genau einer gewinnt, während der Rest einen sauberen Konfliktfehler bekommt.
Gleichzeitiger Ansturm auf einen Slot (orientierend)
Die Prüfung ist kontrafaktisch: Entfernen Sie die Unique-Bedingung, und derselbe Test lässt plötzlich zwei Buchungen durch. Wenn der Test grün bleibt, nachdem die Absicherung weg ist, hat er nichts bewacht.
Ein Gewinner, immer
Das Ergebnis ist eine Plattform, die sich unter Last genauso verhält wie bei einem einzigen Nutzer: Ein Slot hat einen Besitzer, Punkt. Es gibt keinen Zustand, in dem zwei Personen mit demselben Termin davongehen, denn diese Möglichkeit wurde an der Quelle herausgeschnitten, in der Datenbank, nicht in der Oberfläche zusammengeflickt.
Weitere Projekte
Weitere Projekte aus derselben Kategorie - sehen Sie, wie wir ähnliche Herausforderungen angehen.
Haben Sie ein ähnliches Projekt?
Melden Sie sich - ein Angebot ist kostenlos und kommt innerhalb einer Stunde.