Több pincér, egy asztal: konfliktusfeloldás a rendelés rétegben

Az antalyai Belekben rendezett 1200 fős banketten négy pincér egyszerre vesz fel ételeket ugyanahhoz a 20 személyes kerek asztalhoz. A klasszikus "last-write-wins" csendben felülír 14 tételt. Megmutatjuk, hogyan vezettük be élesben az optimista zárolást, a 409 Conflictot és az újrapróbálkozási mintát.

Miért kevés a last-write-wins

Az egyszerű UPDATE orders SET items = ? WHERE id = ? csak az utolsó committet tartja meg. Négy POST 200 ms alatt, és a konyha 20-ból 6 fogást lát.

Megoldás: minden sor kap egy version oszlopot. A kliens megnyitáskor olvassa, mentéskor visszaküldi, a szerver atomi módon ellenőrzi.

Optimista zárolás verziókkal

Adjuk hozzá: version INTEGER és updated_at. PATCH:

• Kliens: { items, expected_version: 7 }.
• Szerver: UPDATE ... WHERE id = ? AND version = 7.
• 0 sor → 409 Conflict + aktuális állapot.

409 Conflict + kliensoldali merge

Nincs auto-retry. A kliens megmutatja a legfrissebb rendelést, kiemeli a változtatásokat, és megerősítést kér. Belekben az érzékelt konfliktusarány 0,4%-ról 0%-ra csökkent.

Az append-only order_events napló triviális auditot ad.

GYIK

Miért ne SELECT FOR UPDATE? Sorba állítja a pincéreket és vágja az átbocsátóképességet.

D1-en működik? Igen, INTEGER-en az atomi UPDATE biztonságos.

És offline? Helyi sor + expected_version, merge újracsatlakozáskor.

Hasznosnak találtad? Oszd meg.