Pazaryeri entegrasyonunda stok karışıklığını önleyen mimari

Birden fazla kanaldan satış yapan her mağaza er ya da geç aynı sorunu yaşıyor: elde bir adet kalan ürün iki kanaldan aynı anda satılıyor. Sonuç iptal, müşteri memnuniyetsizliği ve pazaryerinde performans puanı düşüşü. Bu yazı sorunun neden kaçınılmaz olmadığını ve mimarinin nasıl kurulması gerektiğini anlatıyor.

Sorunun kaynağı: senkronizasyon gecikmesi

Pazaryerleri stok güncellemesini anlık almaz. Çoğu, dakikalar mertebesinde bir gecikmeyle işler ve kendi tarafında da bir kuyruk tutar. Yani siz stoğu sıfıra çektiğinizde, pazaryeri hâlâ birkaç dakika boyunca o ürünü satılabilir gösterebilir.

Bu gecikme ortadan kaldırılamaz. Mimari, gecikmeyi yok saymak yerine onu hesaba katmak zorundadır.

Kural 1: Tek doğruluk kaynağı

Stoğun gerçek değerinin tutulduğu tek bir sistem olmalı. Bu genelde ERP'niz ya da kendi e-ticaret veritabanınızdır. Pazaryerleri bu kaynağın kopyasını taşır, asla kendileri kaynak olmaz.

Sık yapılan hata, her kanalın kendi stoğunu tutup periyodik olarak "eşitlenmeye" çalışmasıdır. İki kaynak varsa çakışma kaçınılmazdır ve hangisinin doğru olduğuna karar verecek bir kural yoktur.

Kural 2: Kanal başına tampon ayırın

Toplam stoğun tamamını her kanala açmayın. Elinizde 10 adet varsa her kanala 10 göstermek yerine, satış hızına göre bölüştürün ve bir kısmını tampon olarak ayırın.

// Kanal başına yayınlanacak stok
// Tampon, senkronizasyon gecikmesi süresince gelebilecek siparişi karşılar.
function yayinlanacakStok({ gercekStok, kanalPayi, gunlukSatisHizi, gecikmeDakika }) {
  // Gecikme süresinde beklenen satış adedi
  const gecikmedeBeklenenSatis = Math.ceil(
    (gunlukSatisHizi / (24 * 60)) * gecikmeDakika
  )

  const tampon = Math.max(1, gecikmedeBeklenenSatis)
  const pay = Math.floor(gercekStok * kanalPayi)

  return Math.max(0, pay - tampon)
}

Tampon boyutunu ürünün satış hızına göre değiştirin. Ayda bir satan bir üründe 1 adet tampon yeterlidir; günde elli satan üründe daha fazlası gerekir. Sabit bir tampon değeri her iki uçta da yanlış sonuç verir.

Kural 3: Rezervasyon, düşüm değil

Sipariş geldiğinde stoğu doğrudan düşürmek yerine rezerve edin. Rezervasyon, ödeme onaylanana kadar tutulur; onaylanınca gerçek düşüme dönüşür, iptal olursa serbest kalır.

Bu ayrım özellikle kapıda ödeme ve havale gibi gecikmeli ödeme yöntemlerinde kritiktir. Rezervasyonlara zaman aşımı koyun — aksi halde tamamlanmayan siparişler stoğu kilitler.

• Sipariş oluştu → rezervasyon açılır, yayınlanan stok düşer
• Ödeme onaylandı → rezervasyon gerçek stok düşümüne dönüşür
• Ödeme başarısız veya süre doldu → rezervasyon serbest bırakılır
• İade → stok geri eklenir, kanal senkronizasyonu tetiklenir

Kural 4: Olay tabanlı senkronizasyon

Her beş dakikada bir tüm kataloğu tarayıp göndermek (tam senkronizasyon) hem yavaştır hem API kotanızı tüketir. Bunun yerine stok değiştiğinde bir olay üretin ve yalnızca değişen ürünü gönderin.

Tam senkronizasyonu tamamen bırakmayın ama sıklığını düşürün — günde bir kez, gece. Bu, kaçan olayları yakalayan bir güvenlik ağıdır.

Kural 5: Kuyruk ve yeniden deneme

Pazaryeri API'leri düzenli olarak hata döner: kota aşımı, geçici kesinti, zaman aşımı. Güncellemeleri doğrudan göndermek yerine bir kuyruğa yazın ve kuyruk işleyicisi göndersin.

Yeniden denemede üstel geri çekilme (exponential backoff) kullanın: 1 sn, 2 sn, 4 sn, 8 sn. Aynı ürün için kuyrukta bekleyen eski güncellemeyi yenisiyle değiştirin — sadece en son değer önemlidir.

Kural 6: Aşırı satışı ölçün

Sıfır aşırı satış gerçekçi bir hedef değil. Gerçekçi hedef, oranı bilinen ve kabul edilebilir bir seviyede tutmaktır. Şunları takip edin:

• Stok yetersizliği nedeniyle iptal edilen sipariş oranı (kanal bazında)
• Senkronizasyon gecikmesinin gerçek ortalaması ve en kötü değeri
• Kuyrukta bekleyen güncelleme sayısı — yükseliyorsa bir yerde tıkanma var
• Başarısız API çağrısı oranı

Bu metrikler bir panelde durmalı. Aşırı satış oranı yükseldiğinde sebebini aramak yerine hangi metriğin bozulduğuna bakarsınız.

Özet mimari

Tek stok kaynağı → rezervasyon katmanı → kanal bazlı tampon hesabı → olay kuyruğu → pazaryeri API'leri. Her adımda hata durumu tanımlı, her sayı ölçülüyor.

Bu yapı kurulduktan sonra yeni bir pazaryeri eklemek birkaç günlük iştir; kurulmadan önce her yeni kanal sorunu katlar.

• pazaryeri
• entegrasyon
• stok yönetimi
• e-ticaret