複数のウェイター、同じテーブル:注文層のコンフリクト解決

アンタルヤ・ベレクの1200カバーの宴会で、4人のウェイターが同じ20人席の円卓へ同時に料理を追加します。古典的な「last-write-wins」では14品が静かに消えます。本記事では楽観ロック、409 Conflict、リトライパターンを本番投入する方法を紹介します。

last-write-wins では足りない理由

素朴な UPDATE orders SET items = ? WHERE id = ? は最後の commit だけが残ります。200ミリ秒の間に4つのPOSTが届くと、厨房には20品中6品しか届きません。

解決策は行ごとに version カラムを持つこと。クライアントは開いた時に読み、保存時に送り返し、サーバーは原子的に検証します。

バージョン管理による楽観ロック

version INTEGER と updated_at を追加します。PATCHの流れ:

• クライアント:{ items, expected_version: 7 }。
• サーバー:UPDATE ... WHERE id = ? AND version = 7。
• 0行更新 → 409 Conflict + 現在の状態。

409 Conflict とクライアント側マージ

自動リトライはしません。最新の注文を表示し、追加/削除の差分を強調し、ユーザーの確認を待ちます。ベレクでは体感コンフリクト率が 0.4% から 0% へ。

追記専用ログ order_events を併用すれば監査も簡単です。

FAQ

SELECT FOR UPDATE ではダメ?ウェイターを直列化しスループットが落ちます。

D1 で動く?はい、INTEGER の原子的 UPDATE は安全です。

オフラインは?ローカルキュー + expected_version、再接続時にマージUI。

お役に立ちましたか?シェアしてください。