Eén voorraad, drie marketplaces: Getir + Trendyol GO + Yemeksepeti integratie

Een döner-keten met 4 vestigingen in Izmir Alsancak is tegelijk verbonden met Getir Yemek, Trendyol GO en Yemeksepeti. In plaats van drie aparte menu's gebruiken ze thMenu als master record; voorraadafnames gebeuren op één plek en een webhook fan-out werkt drie platforms bij.

Master-record architectuur

De kolom products.stock_quantity in D1_MENU is de enige canonieke bron. Bij orderbevestiging: UPDATE products SET stock_quantity = stock_quantity - 1 WHERE id = ? AND stock_quantity > 0. 0 rijen geraakt = uitverkocht.

Bij succes gaat er een event naar Cloudflare Queue. Drie workers patchen parallel de API's. Gemiddelde fan-out latency 340 ms.

Conflictoplossing

Scenario: 5 lahmacun op voorraad. In dezelfde seconde komen 5 orders binnen via drie platforms. De atomaire UPDATE serialiseert — de laatste vindt 0 en wordt geweigerd. Eindstand 0, drie "uitverkocht"-signalen.

D1 heeft geen expliciete row locks maar WHERE stock > 0 vervult dezelfde rol. Nul over-sell in 6 maanden.

Drift-reconciliatie

Yemeksepeti-webhook heeft 30 s vertraging, Trendyol is direct, Getir polled elke 5 s. Een uurlijkse cron vergelijkt alle drie met de master.

• Yemeksepeti 5, Getir 3: master op 5, Getir PATCH
• Master 0, platform 2: direct 0 PATCH
• Drift > 3: Slack-alert

FAQ

Moet ik per platform handmatig menu's invoeren? Nee, master record + fan-out automatiseren alles.

Wie krijgt prioriteit bij een race? FIFO op timestamp; de verliezer krijgt 422.

Is de cron handmatig? Nee, uurlijks op Workers, Slack-alert bij grote drift.

Was dit nuttig? Deel het.