slotline
Platforma rezerwacji zasobów (sale, korty, sprzęt) na Spring Boot. Rdzeń gwarantuje, że jeden slot nigdy nie zostanie zarezerwowany podwójnie - nawet przy dużej równoległości.
Platforma rezerwacji zasobów (sale, korty, sprzęt) na Spring Boot. Wygląda banalnie, dopóki dwie osoby nie klikną tego samego slotu w tej samej milisekundzie. Rdzeń gwarantuje, że jeden termin nigdy nie zostanie zarezerwowany podwójnie, nawet przy dużej równoległości.
Wprowadzenie
Rezerwacja terminu to z pozoru wpis do tabeli i wielu programistów tak właśnie ją pisze. Problem w tym, że prawdziwa trudność nie leży w typowym użyciu, tylko w jednej milisekundzie, w której dwie osoby sięgają po ten sam wolny slot. slotline jest zbudowany wokół tej jednej milisekundy, a nie wokół formularza rezerwacji.
Cała reszta platformy, czyli zasoby, kalendarz i widoki, obudowuje jedną gwarancję: że slot ma dokładnie jednego zwycięzcę. To ona decyduje, czy system jest poważny, czy tylko wygląda, że działa do pierwszego tłumu.
Cała trudność siedzi w jednej milisekundzie
Naiwna implementacja robi dwa kroki: sprawdza, czy slot jest wolny, a potem go zapisuje. Między tymi krokami jest szczelina, w której drugi użytkownik zdąży zobaczyć ten sam slot jako wolny. Oboje przechodzą sprawdzenie, oboje zapisują, i masz dwie rezerwacje na jeden termin, o których nikt nie wiedział, że są możliwe.
slotline traktuje to jako główny problem do rozwiązania, a nie przypadek brzegowy. Model domeny jest czytelny właśnie po to, żeby ta jedna gwarancja była oczywista przy czytaniu kodu, a nie ukryta gdzieś w warstwie serwisowej.
Sprawdzenie dostępności i zapis rezerwacji to nie są dwie osobne operacje. Jeśli są, masz wyścig. Gwarancję daje baza, przez unikalny warunek na zasób i przedział czasu, nie sprawdzenie w kodzie aplikacji.
Unikalny warunek przenosi rozstrzygnięcie w jedyne miejsce, w którym równoległość jest szeregowana naprawdę: do silnika bazy. Nie ma znaczenia, ilu użytkowników klika naraz, bo o zwycięzcy rozstrzyga atomowy zapis, a przegrani dostają czysty błąd konfliktu zamiast cichej podwójnej rezerwacji.
Test, który naprawdę może paść
Łatwo napisać test, który rezerwuje raz i sprawdza, że się udało. To niczego nie dowodzi, bo nie dotyka warunku, który ma trzymać. Wartościowy test odpala wiele wątków naraz na tym samym slocie i sprawdza, że dokładnie jeden wygrywa, a reszta dostaje czysty błąd konfliktu.
Równoczesny szturm na jeden slot (orientacyjnie)
Sprawdzian jest kontrfaktyczny: zdejmij unikalny warunek i ten sam test zaczyna przepuszczać dwie rezerwacje. Jeśli po usunięciu zabezpieczenia test dalej jest zielony, to nie pilnował niczego.
Jeden zwycięzca, zawsze
Efektem jest platforma, która pod obciążeniem zachowuje się tak samo jak przy jednym użytkowniku: slot ma jednego właściciela i kropka. Nie ma stanu, w którym dwie osoby wychodzą z tym samym terminem, bo taka możliwość została wycięta u źródła, w bazie, a nie załatana w interfejsie.
Więcej projektów
Inne realizacje z tej samej kategorii - zobacz, jak podchodzimy do podobnych wyzwań.
Masz podobny projekt?
Napisz do nas - wycena jest bezpłatna i wraca w godzinę.



