Ein Inventar, drei Marktplätze: Getir + Trendyol GO + Yemeksepeti Integration

Eine Döner-Kette mit 4 Filialen in Izmir Alsancak ist gleichzeitig mit Getir Yemek, Trendyol GO und Yemeksepeti verbunden. Statt drei separate Menüs zu pflegen, nutzen sie thMenu als Master Record; Bestandsabzüge laufen zentral, ein Webhook Fan-Out aktualisiert alle drei Plattformen.

Master-Record-Architektur

Die D1_MENU-Spalte products.stock_quantity ist die einzige kanonische Quelle. Bei Bestellbestätigung läuft ein atomares UPDATE: UPDATE products SET stock_quantity = stock_quantity - 1 WHERE id = ? AND stock_quantity > 0. 0 betroffene Zeilen = ausverkauft.

Bei Erfolg geht ein Event an die Cloudflare Queue. Drei Worker patchen parallel die Plattform-APIs. Durchschnittliche Fan-Out-Latenz: 340 ms.

Race Conditions auflösen

Szenario: 5 Lahmacun auf Lager. In derselben Sekunde kommen 5 Bestellungen aus drei Plattformen. Das atomare UPDATE serialisiert sie — die letzte findet stock=0 und wird abgelehnt. Final-State 0, drei "out of stock"-Signale fließen aus.

D1 hat keine expliziten Row Locks, aber WHERE stock > 0 erfüllt den gleichen Zweck. Null Over-Sell-Vorfälle in 6 Monaten.

Drift-Reconciliation

Yemeksepetis Webhook hat 30 s Verzögerung, Trendyol ist sofort, Getir pollt im 5-s-Takt. Ein stündlicher Cron vergleicht alle drei mit dem Master.

• Yemeksepeti 5, Getir 3: Master auf 5 setzen, Getir nachziehen
• Master 0, Plattform 2: sofort 0 patchen
• Drift > 3: Slack-Alert + Review

FAQ

Müssen Menüs auf jeder Plattform manuell gepflegt werden? Nein, Master Record verteilt Änderungen automatisch.

Wie wird Priorität bestimmt? FIFO nach Timestamp — Verlierer erhält 422.

Wer überwacht den Drift? Stündlicher Cron, bei großem Drift Slack-Webhook.

Hilfreich? Teilen Sie es.