Più camerieri, stesso tavolo: conflict resolution sugli ordini

In un banchetto da 1200 coperti ad Antalya Belek, quattro camerieri aggiungono piatti contemporaneamente allo stesso tavolo rotondo da 20 persone. Il classico "last-write-wins" sovrascrive in silenzio 14 articoli. Ecco come abbiamo portato in produzione optimistic locking, 409 Conflict e il pattern di retry.

Perché last-write-wins non basta

Un UPDATE orders SET items = ? WHERE id = ? tiene solo l'ultimo commit. 4 POST in 200ms e solo 6 piatti su 20 arrivano in cucina.

Soluzione: una colonna version per riga. Il client la legge in apertura e la reinvia in scrittura; il server verifica in modo atomico.

Optimistic locking con versioning

Aggiungi version INTEGER e updated_at. PATCH:

• Client: { items, expected_version: 7 }.
• Server: UPDATE ... WHERE id = ? AND version = 7.
• 0 righe → 409 Conflict + stato corrente.

409 Conflict + merge lato client

Nessun retry automatico. Il client mostra l'ordine aggiornato, evidenzia le modifiche e chiede conferma. A Belek i conflitti percepiti sono scesi dallo 0,4 % allo 0 %.

Un log append-only order_events rende ogni passaggio auditabile.

FAQ

Perché non SELECT FOR UPDATE? Serializza i camerieri e taglia il throughput.

Funziona su D1? Sì, UPDATE atomico su INTEGER non innesca anti-pattern.

E offline? Coda locale + expected_version, merge al rientro.

Ti è stato utile? Condividilo.