単一在庫、3つのマーケットプレイス:Getir + Trendyol GO + Yemeksepeti 統合

イズミル・アルサンジャクの4店舗ドネルチェーンはGetir Yemek、Trendyol GO、Yemeksepetiに同時接続している。3つの別々のメニューを維持する代わりに、thMenuをマスターレコードとして使用。在庫減算は1か所で行われ、webhookファンアウトが3プラットフォームを更新する。

マスターレコードアーキテクチャ

D1_MENUテーブルのproducts.stock_quantityが唯一の正規ソース。注文確定時にアトミックUPDATE:UPDATE products SET stock_quantity = stock_quantity - 1 WHERE id = ? AND stock_quantity > 0。0行影響=完売。

成功するとイベントがCloudflare Queueへ。3つのworkerが並行してAPIをPATCH。平均ファンアウト遅延は340ミリ秒。

競合解決

シナリオ:在庫5個のlahmacun。同じ秒に3プラットフォームから5件注文が到着。アトミックUPDATEが直列化し、最後の注文は0を見つけて拒否。最終状態0、3つの「品切れ」信号がファンアウト。

D1には明示的な行ロックはないが、WHERE stock > 0が同じ役割。6か月で過剰販売ゼロ。

ドリフト調整

Yemeksepetiのwebhookは30秒遅延、Trendyolは即時、Getirは5秒ポーリング。1時間ごとのcronが3者をマスターと比較。

• Yemeksepeti 5、Getir 3:マスター5、Getirを5にPATCH
• マスター0、プラットフォーム2:即座に0にPATCH
• ドリフト>3:Slackアラート

FAQ

各プラットフォームにメニューを手動入力しますか?いいえ、マスターレコード+ファンアウトで全自動。

競合時の優先順位は?timestamp順FIFO、敗者は422。

cronは手動?いいえ、Workers上で毎時自動、ドリフト大きいときSlackアラート。

お役に立ちましたか?シェアしてください。