Meerdere obers, één tafel: conflict resolution op orderniveau

Bij een banquet voor 1200 couverts in Antalya Belek voegen vier obers tegelijkertijd gerechten toe aan dezelfde ronde tafel voor 20 personen. Het klassieke "last-write-wins" overschrijft stilzwijgend 14 items. Hier lees je hoe we optimistic locking, 409 Conflict en een retry-pattern productie-klaar maakten.

Waarom last-write-wins faalt

Een eenvoudige UPDATE orders SET items = ? WHERE id = ? bewaart enkel de laatste commit. Vier POSTs in 200ms? De keuken ziet 6 gerechten van de 20.

Oplossing: elke rij krijgt een version-kolom. Client leest die bij openen, stuurt mee bij opslaan, server controleert atomisch.

Optimistic locking met versionering

Voeg version INTEGER en updated_at toe. PATCH:

• Client: { items, expected_version: 7 }.
• Server: UPDATE ... WHERE id = ? AND version = 7.
• 0 rijen → 409 Conflict + huidige status.

409 Conflict + merge bij de client

Geen auto-retry. De client toont het actuele order, markeert wijzigingen en vraagt bevestiging. In Belek daalde de gevoelde conflictrate van 0,4% naar 0%.

Een append-only order_events-log maakt audit triviaal.

FAQ

Waarom geen SELECT FOR UPDATE? Serialiseert obers en knipt throughput.

Werkt op D1? Ja, atomische UPDATE op INTEGER is veilig.

En offline? Lokale queue + expected_version, merge bij reconnect.

Was dit nuttig? Deel het.