Ett lager, tre marknadsplatser: Getir + Trendyol GO + Yemeksepeti integration

En döner-kedja med 4 filialer i Izmir Alsancak är samtidigt ansluten till Getir Yemek, Trendyol GO och Yemeksepeti. Istället för att underhålla tre separata menyer använder de thMenu som master record; lageravdrag sker på ett ställe och en webhook fan-out uppdaterar tre plattformar.

Master record-arkitektur

Kolumnen products.stock_quantity i D1_MENU är den enda kanoniska källan. Vid orderbekräftelse: UPDATE products SET stock_quantity = stock_quantity - 1 WHERE id = ? AND stock_quantity > 0. 0 rader = slut.

Vid framgång går en händelse till Cloudflare Queue. Tre workers patchar API:er parallellt. Genomsnittlig fan-out-latens 340 ms.

Konfliktlösning

Scenario: 5 lahmacun i lager. Inom samma sekund kommer 5 ordrar från tre plattformar. Atomär UPDATE serialiserar — den sista finner 0 och avvisas. Sluttillstånd 0, tre "slut"-signaler.

D1 har inga explicita row locks men WHERE stock > 0 fyller samma roll. Noll översäljning på 6 månader.

Drift-avstämning

Yemeksepetis webhook har 30 s fördröjning, Trendyol är omedelbar, Getir pollar var 5:e sekund. En timvis cron jämför alla tre med master.

• Yemeksepeti 5, Getir 3: master till 5, PATCH Getir
• Master 0, plattform 2: omedelbar PATCH 0
• Drift > 3: Slack-varning

FAQ

Måste menyer matas in manuellt på varje plattform? Nej, master record + fan-out automatiserar allt.

Vem får prioritet vid race? FIFO efter timestamp, förloraren får 422.

Är cron manuell? Nej, timvis på Workers med Slack-varning vid stor drift.

Var detta hjälpsamt? Dela det.