Mehrere Kellner, ein Tisch: Conflict Resolution auf Order-Ebene

In einem 1200-Cover-Bankett in Antalya Belek fügen vier Kellner gleichzeitig Artikel an denselben 20-Personen-Tisch hinzu. Das klassische "Last-Write-Wins"-Verhalten überschreibt 14 Artikel der ersten drei Kellner stillschweigend. So implementieren wir Optimistic Locking, 409 Conflict und einen Retry-Pattern produktionsreif.

Warum Last-Write-Wins versagt

Ein simples UPDATE orders SET items = ? WHERE id = ? akzeptiert nur den letzten Commit. Bei 4 parallelen POSTs in 200ms gewinnt der Zufall — und der Gast bekommt eine Rechnung mit 6 statt 20 Positionen.

Die Lösung: jede Zeile bekommt eine version-Spalte. Beim Öffnen liest der Client die Version, beim Schreiben sendet er sie mit, und der Server prüft sie atomar.

Optimistic Locking mit Versionierung

Erweitere das Schema um version INTEGER DEFAULT 1 und updated_at INTEGER. PATCH-Logik:

• Client sendet { items, expected_version: 7 }.
• Server: UPDATE ... WHERE id = ? AND version = 7.
• Affected rows = 0 → 409 Conflict + aktueller Zustand.

409 Conflict + Merge-UI

Der Client startet kein Auto-Retry. Stattdessen zeigt er die neueste Bestellung, hebt die geplanten Änderungen hervor und wartet auf Bestätigung. In Belek sank die wahrgenommene Konfliktrate von 0,4 % auf 0 %.

Ein Append-only-Log order_events dokumentiert jeden Schritt — perfekt für Audits und Schichtgespräche.

FAQ

Warum kein SELECT FOR UPDATE? Es serialisiert die Kellner. Optimistic Locking ist bei seltenen Konflikten viel schneller.

Funktioniert das in Cloudflare D1? Ja, atomares Single-Row-UPDATE auf INTEGER ist sicher und triggert kein Anti-Pattern.

Und Offline-Clients? Local-First-Queue plus expected_version. Bei Sync ggf. Merge-UI öffnen.

Hilfreich? Teilen Sie es.