Pazaryeri Entegrasyon Yönetimi: Trendyol, Hepsiburada, Amazon

Trendyol'da bir Excel, Hepsiburada'da ayrı bir panel, Amazon'da başka bir ekran, N11'de bambaşka bir akış. Türkiye'de çoklu pazaryerinde satan işletmelerin büyük çoğunluğu stoğu, fiyatı ve siparişi her kanalda elle, ayrı ayrı yönetiyor. Her kanal kendi gerçeğini tutuyor, hiçbiri diğerinden haberdar değil; aradaki tutarsızlığı ise bir kişi gün boyu sekme arasında gezinerek elle kapatmaya çalışıyor. Sonuçta üç tür kayıp aynı anda yaşanıyor: son adedi iki pazaryerinde birden satıp iptal etmek zorunda kalmak (over-sell), bir kanalda kampanya fiyatını güncellemeyi unutup zararına satmak, ve siparişi geç fark edip pazaryerinin teslim süresini (SLA) kaçırıp puan/ceza yemek. Bu üçü, ciro büyüdükçe katlanarak artan operasyonel bir borç: ürün adedi ve kanal sayısı arttıkça elle takip fiziksel olarak imkânsız hale geliyor. Pazaryeri entegrasyonu dediğimizde ilk müdahale ettiğimiz nokta tam olarak budur: stoğu, fiyatı ve siparişi tek bir merkezden, olay tabanlı ve idempotent şekilde tüm kanallara yayan; ürün listelemeyi otomatikleştiren ve sipariş akışını tek kuyrukta orkestre eden bir entegrasyon katmanı kurmak.

Yaklaşımımız

Pazaryeri entegrasyon projelerinde ilk kararımız her zaman tek bir doğruluk kaynağı belirlemek oluyor. Çoklu kanal kaosunun kökeni, her pazaryerinin kendi stok ve fiyatını ayrı tutması ve hiçbirinin diğerinden haberdar olmaması. Bu yüzden stoğu, fiyatı ve ürün master verisini merkezi bir PIM ve PostgreSQL üzerinde toplamayı; pazaryerlerini ise yalnızca bu merkezin yansıması olarak konumlandırmayı öneriyoruz. Hiçbir kanal kendi başına otorite değil; bir kanaldan gelen sipariş bile merkezi sayacı düşürmek için bir olay; pazaryeri o stoğun sahibi değil. Bu ilke baştan konmazsa, ne kadar hızlı senkron yaparsanız yapın over-sell tam olarak kapanmaz; çünkü iki ayrı otoritenin aynı adedi farklı bildiği bir anı her zaman yakalarsınız. Bu yüzden mimariye başlamadan önce hangi verinin nerede yaşayacağını netleştirmeyi tercih ediyoruz.

İkinci kritik karar olay tabanlı (event-driven) senkronizasyon. Stok veya fiyat değiştiğinde her kanalı tek tek dolaşıp güncellemek (polling) hem yavaş hem rate-limit yiyen bir yaklaşım; kanal sayısı arttıkça bu maliyet doğrusal değil, çarpan etkisiyle büyüyor. Bunun yerine değişikliği bir olay olarak RabbitMQ ya da Kafka'ya yayınlamayı, her pazaryeri için ayrı bir tüketici (consumer) servisinin bu olayı kendi API'sine yazmasını öneriyoruz. Bu mimari iki şeyi birden çözüyor: değişiklik saniyeler içinde tüm kanallara dağılıyor, ve her kanal kendi hızında çalışabildiği için biri yavaşsa ya da geçici olarak çökse diğerlerini bloklamıyor; kuyrukta bekleyen olaylar kanal toparlandığında işleniyor, hiçbir güncelleme kaybolmuyor. Sıcak veriyi (anlık stok, aktif sipariş) Redis'te tutarak hem okuma yükünü hem de eşzamanlılık kilitlerini bu katmanda yönetiyoruz.

Üçüncü katman, pazaryerleriyle çalışan herkesin er ya da geç çarptığı duvar: rate-limit, retry ve idempotency. Trendyol, Hepsiburada, Amazon SP-API ve N11'in her biri farklı bir hız sınırı ve hata davranışı dayatıyor. Her kanal için token-bucket tabanlı bir hız sınırlayıcı koyuyoruz; istekler kuyruktan kontrollü hızda çekiliyor, ani yük doğrudan API'ye vurmuyor. Geçici hatalarda (429, 5xx) jitter'lı exponential backoff ile yeniden deniyoruz; kalıcı hatalar dead-letter kuyruğuna düşüyor. En kritik nokta ise idempotency: sipariş onayı, stok güncelleme gibi yazma işlemleri retry sırasında iki kez tetiklenirse çift kayıt oluşmaması için her işleme bir idempotency anahtarı veriyoruz. Bu, "ağ koptu, acaba istek gitti mi" belirsizliğinde sistemi güvenli kılan tek mekanizma.

Son katman ürün listeleme otomasyonu ve sipariş orkestrasyonu. Merkezi PIM'de bir kez tanımlanan ürünü, kanal başına bir eşleştirme katmanıyla her pazaryerinin kendi kategori ağacına ve zorunlu özellik setine çevirip otomatik listelemeyi; gelen siparişleri tek bir kuyrukta toplayıp durum makinesiyle (yeni → onaylı → kargoda → teslim) yönetmeyi öneriyoruz. Tüm operasyon Next.js tabanlı tek bir panelde toplanıyor; hangi kanalın throttle yediği, hangi ilanın reddedildiği, hangi siparişin SLA'ya yaklaştığı buradan görünüyor. Sentry ile hata ve gecikme izleme baştan kuruluyor; entegrasyonun sessizce bozulduğu senaryo, en pahalı senaryodur.

Tercih Ettiğimiz Teknolojiler

Tipik tercihlerimiz aşağıdaki gibi; çalıştığınız pazaryerlerine, ürün adedine ve sipariş hacmine göre uyarlıyoruz.