En un banquete de 1200 cubiertos en Antalya Belek, cuatro camareros añaden platos a la misma mesa redonda de 20 personas al mismo tiempo. El clásico "last-write-wins" sobrescribe en silencio 14 artículos. Aquí explicamos cómo desplegamos en producción optimistic locking, 409 Conflict y el patrón de retry.
Por qué last-write-wins falla
Un UPDATE orders SET items = ? WHERE id = ? sólo guarda el último commit. Con 4 POST en 200ms, sólo 6 de 20 platos llegan a cocina.
La solución: una columna version por fila. El cliente la lee al abrir y la reenvía al guardar; el servidor verifica atómicamente.
Optimistic locking con versionado
Añade version INTEGER y updated_at. PATCH:
- Cliente:
{ items, expected_version: 7 }. - Servidor:
UPDATE ... WHERE id = ? AND version = 7. - 0 filas afectadas →
409 Conflict+ estado real.
409 Conflict + fusión en cliente
No hay reintento automático. El cliente muestra el pedido actualizado, resalta cambios y pide confirmación. En Belek, los conflictos percibidos cayeron del 0,4 % al 0 %.
Añade un log append-only order_events para auditar quién hizo qué y cuándo.
FAQ
¿Y SELECT FOR UPDATE? Serializa a los camareros y reduce el throughput.
¿Funciona en D1? Sí, UPDATE atómico sobre INTEGER es seguro.
¿Y offline? Cola local + expected_version, fusión al reconectar.
¿Te resultó útil? Compártelo.
Artículos relacionados
¿Qué es un menú QR? La guía completa para restaurantes
Un menú QR permite a tus clientes acceder a tu carta al instante desde el móvil,…
Pasar del menú en papel al menú QR digital: guía paso a paso
¿Quieres adoptar los menús QR pero no sabes por dónde empezar? Esta guía cubre f…
Menús QR geolocalizados: servir distintos idiomas según la IP del visitante
Cómo un resort de 180 plazas en Antalya enruta el mismo QR a menús turcos, alema…