Несколько официантов, один стол: разрешение конфликтов в заказе

На банкете в Анталии (Белек) на 1200 кувертов четыре официанта одновременно добавляют блюда к одному круглому столу на 20 человек. Классический "last-write-wins" молча перезаписывает 14 позиций. Ниже — как мы вывели в продакшн оптимистическую блокировку, 409 Conflict и retry-паттерн.

Почему last-write-wins недостаточно

Простой UPDATE orders SET items = ? WHERE id = ? оставит только последний коммит. Четыре POST за 200мс — и на кухню уйдёт 6 из 20 блюд.

Решение: колонка version в каждой строке. Клиент читает её при открытии, отправляет при записи, сервер проверяет атомарно.

Оптимистическая блокировка с версионированием

Добавьте version INTEGER и updated_at. PATCH:

• Клиент: { items, expected_version: 7 }.
• Сервер: UPDATE ... WHERE id = ? AND version = 7.
• 0 затронутых строк → 409 Conflict + текущее состояние.

409 Conflict + merge на клиенте

Без авто-ретрая. Клиент показывает свежий заказ, подсвечивает изменения и просит подтверждение. В Белеке восприятие конфликтов упало с 0,4 % до 0 %.

Append-only лог order_events делает аудит тривиальным.

FAQ

Почему не SELECT FOR UPDATE? Сериализует официантов и режет throughput.

Работает в D1? Да, атомарный UPDATE по INTEGER безопасен.

А оффлайн? Локальная очередь + expected_version, merge при подключении.

Было полезно? Поделитесь.