Çoklu Garson, Bir Masa: Sipariş Katmanında Conflict Resolution

Antalya Belek'teki 1200 cover'lık bir resort banquet salonunda, 20 kişilik yuvarlak masaya 4 farklı garson aynı anda sipariş ekliyor. POS'taki klasik "last-write-wins" mantığı son yazanın kazandığı, diğer 3 garsonun girdiklerinin sessizce kaybolduğu bir senaryo doğuruyor. Bu yazıda optimistic locking ile 409 Conflict + retry pattern'ı üretim ortamında nasıl kurguladığımızı anlatıyoruz.

Problem: Last-Write-Wins Neden Yetmez

Klasik UPDATE orders SET items = ? WHERE id = ? sorgusunda 4 garson 200ms içinde POST atınca, MySQL/D1 son commit'i yazar; ilk 3 garsonun eklediği toplam 14 ürün sessizce kaybolur. Misafir adisyon istediğinde sürpriz: 6 ürün, 20 sipariş.

Çözümün özü her sipariş satırının updated_at ya da bir version kolonuna sahip olması. Garson order'ı düzenlemek için açtığında client'a versiyon gönderiyoruz; POST geri geldiğinde sunucu versiyonu doğruluyor.

Optimistic Locking ile Versiyonlama

Schema'ya iki kolon eklenir: version INTEGER DEFAULT 1 ve updated_at INTEGER. PATCH endpoint'i:

• Client gönderir: { items: [...], expected_version: 7 }
• Server SQL: UPDATE orders SET items = ?, version = version + 1, updated_at = ? WHERE id = ? AND version = 7
• Affected rows = 0 ise başka garson araya girmiş demektir → 409 Conflict + güncel state döner.

409 Conflict + Client-Side Merge

Client 409 alınca otomatik retry yapmaz — kullanıcıya "Masanın güncel sipariş listesi" gösterir, kendi taslağını üstüne ekleme/çıkarma olarak işaretletir, "Onayla" diyince yeni versiyonla tekrar POST atar. Belek'teki uygulamada bu UX %0.4 conflict oranını %0'a indirdi, garsonların güveni arttı.

Append-only event log (order_events tablosu) tutmak ayrıca audit için kritik. Hangi garson hangi ürünü hangi saatte ekledi/sildi, conflict çıkarsa kim önceydi — hepsi rapor edilebilir.

FAQ

Pessimistic lock (SELECT FOR UPDATE) daha basit değil mi? Banquet senaryosunda 4 garson sırayla bekler, UX kötüleşir. Optimistic locking çakışma nadirken çok daha hızlıdır.

D1'de version kolonu güvenli mi? Evet, INTEGER kolon ve atomic UPDATE D1'de çalışır. JOIN + GROUP BY anti-pattern'a girmez.

Mobile offline'da çalışır mı? Local-first queue + expected_version cache'i ile evet — sync sırasında 409 çıkarsa kullanıcıya merge UI gösterilir.

Faydalı buldunuz mu? Paylaşın.