Wielu kelnerów, jeden stół: rozwiązywanie konfliktów w zamówieniach

Na bankiecie w Antalya Belek dla 1200 osób czterech kelnerów jednocześnie dodaje dania do tego samego okrągłego stołu dla 20 osób. Klasyczny "last-write-wins" po cichu nadpisuje 14 pozycji. Oto jak wdrożyliśmy optimistic locking, 409 Conflict i wzorzec retry w produkcji.

Dlaczego last-write-wins nie wystarczy

Proste UPDATE orders SET items = ? WHERE id = ? zostawia tylko ostatni commit. Cztery POST-y w 200ms — kuchnia widzi 6 z 20 dań.

Rozwiązanie: kolumna version w każdym wierszu. Klient czyta ją przy otwarciu, odsyła przy zapisie, serwer weryfikuje atomowo.

Optimistic locking z wersjonowaniem

Dodaj version INTEGER i updated_at. PATCH:

• Klient: { items, expected_version: 7 }.
• Serwer: UPDATE ... WHERE id = ? AND version = 7.
• 0 wierszy → 409 Conflict + aktualny stan.

409 Conflict + merge po stronie klienta

Bez auto-retry. Klient pokazuje aktualne zamówienie, wyróżnia zmiany i prosi o potwierdzenie. W Beleku odczuwalna liczba konfliktów spadła z 0,4% do 0%.

Append-only log order_events ułatwia audyt.

FAQ

Dlaczego nie SELECT FOR UPDATE? Serializuje kelnerów i tnie przepustowość.

Działa na D1? Tak, atomowy UPDATE na INTEGER jest bezpieczny.

A offline? Lokalna kolejka + expected_version, merge przy reconnect.

Czy to było pomocne? Udostępnij.