#Fiyat ve Stok Senkronizasyonunun Önemi
Çoklu pazaryerinde satış yapan bir markanın en büyük operasyonel riski, kanallar arası fiyat ve stok tutarsızlığıdır. Stok bittikten sonra siparişin alınması (oversell), satıcı puanını düşürür, Trendyol ve Hepsiburada'da otomatik para cezalarına yol açar ve aşırı durumlarda mağaza askıya alınır. Yanlış fiyatla satış ise marj kaybı ve manuel iptal yükü doğurur.
Senkronizasyon, yalnızca veri kopyalama değil; eş zamanlılık, sıralama, hata toleransı ve performansı bir arada çözen bir mühendislik problemidir.
#Senkronizasyon Mimarisi: Push vs Pull
İki temel mimari yaklaşım vardır:
- Push (event-driven): ERP veya stok yönetim sisteminde değişiklik olduğunda, sistem ilgili pazaryerlerinin API'sine güncelleme isteği gönderir. Düşük gecikme süresi sağlar, ölçeklenmesi kolaydır.
- Pull (polling): Pazaryerlerinden periyodik olarak veri çekilir. Yalnızca sipariş alma için tercih edilir, fiyat/stok için yetersizdir.
Doğru tasarım, içeriden dışarıya push, dışarıdan içeriye webhook ve polling hibridi şeklindedir.
#Eş Zamanlılık ve Race Condition'lar
En kritik problem, aynı SKU üzerinde birden fazla kanalın eş zamanlı sipariş yaratmasıdır. Klasik senaryo:
- Stok 1 adet, hem Trendyol hem Hepsiburada vitrinde.
- Aynı saniyede her iki kanaldan birer sipariş gelir.
- Sistem her ikisini kabul ederse oversell oluşur.
Çözüm, merkezi stokta atomik decrement ve pessimistic locking kullanmaktır. PostgreSQL'de SELECT FOR UPDATE veya Redis'te Lua scripting ile kritik bölge garanti altına alınır. Stok 0'a düştüğü anda diğer kanallara availability=out_of_stock event'i push edilir.
#Rate Limit Yönetimi
Her pazaryerinin farklı rate-limit kuralları vardır:
- Trendyol: Saatlik 600-1200 istek arası (mağazaya göre değişir)
- Hepsiburada: Endpoint bazlı, dakikada 60-300
- n11: Saatlik 5000 istek
- Amazon SP-API: Token bucket algoritması, endpoint bazlı burst ve restore rate
Bu kurallar token bucket veya leaky bucket algoritmaları ile client tarafında modellenmelidir. İstek throttling'i, her bir pazaryeri için ayrı kuyruklar (queue) ile yapılır. Aynı SKU için pending update'ler debounce edilerek son değer push edilir.
#Toplu Güncelleme ve Batch İşlemler
Binlerce ürün için tek tek istek atmak hem rate-limit'i tüketir hem yavaştır. Trendyol bulk update endpoint'i ile 1000 ürün tek istekte güncellenebilir. Hepsiburada batch import job'ları benzer mantıkla çalışır.
Batch işlemlerde her job'un durumu (pending, in_progress, completed, failed) takip edilmelidir. Başarısız ürünler, başarılı olanları engellemeden retry kuyruğuna alınmalıdır.
#Çoklu Depo ve FBA/FBT Senaryoları
FBT (Fulfilled by Trendyol), Hepsijet Depo ve Amazon FBA gibi platform depoları kullanıldığında stok yönetimi karmaşıklaşır. Bir SKU için:
- Kendi deponuzdaki stok
- Trendyol deposundaki stok
- Amazon FBA stoğu
gibi farklı kaynaklar konsolide edilmelidir. Fulfillment kanalına göre satılabilir stok ayrı hesaplanır. Örneğin Trendyol FBT'deki stoklar yalnızca Trendyol'da satışa açılırken, kendi depo stoğu tüm kanallara dağıtılır.
#Dinamik Fiyatlandırma ve Repricer Mantığı
Rekabetçi pazaryerlerinde repricer (otomatik fiyatlandırma) kuralları kullanılır:
- En düşük rakibin altında kalmak (örnek: -1 TL)
- Buybox kazanma optimizasyonu (Amazon, Hepsiburada)
- Maliyet altına düşmemek için minimum fiyat koruma
- Marj korumalı maksimum fiyat
Repricer her dakika rakip fiyatlarını çeker, kuralları uygular ve yeni fiyatı senkronizasyon motoruna push eder. Anti-loop koruması, kendi rakipleriyle sonsuz fiyat düşürme döngüsüne girmeyi engeller.
#Hata Yönetimi ve Audit Log
Her senkronizasyon olayı, kim tarafından, ne zaman, hangi değer için tetiklendi şeklinde audit log'a yazılmalıdır. API'den dönen 4xx ve 5xx hataları, hata tipine göre işlenir: validation hatası kullanıcıya gösterilir, geçici hata retry kuyruğuna alınır, kalıcı hata dead letter queue'ya düşer.
#i-Pazaryeri Entegrasyon Yaklaşımı
i-Pazaryeri, fiyat ve stok senkronizasyonunu event-sourcing tabanlı bir mimariyle çözer. Her stok ve fiyat değişikliği immutable bir event olarak kaydedilir; kanal-spesifik connector'lar bu event'leri kendi rate-limit kuyruklarında işler. Pessimistic locking ve atomik decrement ile oversell engellenir, debouncing ile gereksiz API çağrıları minimize edilir. Repricer modülü, rakip fiyat takibi, marj koruma ve buybox optimizasyonu kurallarını birleştirir. Çoklu depo (kendi depo, FBT ve FBA) konfigürasyonu, kanal bazında satılabilir stok hesaplamasını otomatikleştirir. Audit log paneli, her değişikliğin geçmişini şeffaf şekilde sunar.
