Pazaryeri Entegrasyon Mimarisi: Stok, Fiyat ve Sipariş Senkronizasyonunda Buffer Yönetimi

Birden fazla pazaryerinde satış yapan işletmeler için entegrasyon, ürünleri API üzerinden göndermekten çok daha kapsamlı bir yazılım problemidir. ERP, e-ticaret platformu, depo, ödeme, kargo ve pazaryeri sistemleri farklı hızlarda çalışır; farklı veri modelleri ve işlem kuralları kullanır. Kampanya başlangıcı, toplu fiyat değişikliği veya yoğun sipariş anı geldiğinde bu farklar aşırı satışa, eski fiyatların yayında kalmasına, mükerrer siparişlere ve operasyon ekiplerinin kaynağını göremediği tutarsızlıklara dönüşebilir.

Dayanıklı bir pazaryeri entegrasyon mimarisi, sistemleri doğrudan ve kontrolsüz biçimde birbirine bağlamak yerine araya yönetilebilir bir buffer, yani kuyruk ve işlem katmanı yerleştirir. Buffer gelen olayları güvenli biçimde saklar, hedef sistemin kaldırabileceği hızda işler, geçici hatalarda yeniden dener ve kalıcı sorunları inceleme kuyruğuna taşır. Böylece trafik yoğunluğu veri kaybına dönüşmez; her işlemin durumu, nedeni ve sonucu izlenebilir.

Buffer yönetimi pazaryeri entegrasyonunda neyi çözer?

ERP saniyede binlerce stok değişikliği üretebilirken bir pazaryeri API’si daha düşük istek kotası uygulayabilir. Benzer şekilde pazaryerinden kısa sürede yüzlerce sipariş gelirken ERP sipariş kabul servisi bakımda olabilir. Doğrudan senkron bağlantıda gönderen sistem yanıt bekler; zaman aşımı oluştuğunda işlemin hedefe ulaşıp ulaşmadığı belirsizleşir. Aynı isteğin tekrar gönderilmesi ise ikinci bir kayıt yaratabilir.

Kuyruk tabanlı yük dengeleme yaklaşımı, üretim hızı ile tüketim hızını birbirinden ayırır. Microsoft’un Queue-Based Load Leveling modeli, değişken yoğunlukta gelen işleri bir kuyrukta tutarak hedef servisin yönetilebilir bir tempoda çalışmasını önerir. Pazaryeri senaryosunda bu model, ani sipariş dalgasının ERP’yi veya toplu stok güncellemesinin pazaryeri API’sini doğrudan zorlamasını önler.

Buffer yalnızca bekleme alanı değildir. Mesajın türü, kaynak sistemi, işletme veya mağaza kodu, ürün ya da sipariş anahtarı, oluşturulma zamanı, sürüm numarası, deneme sayısı ve korelasyon kimliği gibi bağlamı taşımalıdır. Bu bilgiler olmadan kuyruğun dolduğu görülebilir fakat hangi iş kuralının, mağazanın veya ürün grubunun gecikmeye yol açtığı açıklanamaz.

Stok senkronizasyonunda güvenlik payı ve rezervasyon

Stok aktarımında temel soru “ERP’de kaç adet var?” değil, “Bu kanalda güvenle kaç adet satılabilir?” olmalıdır. Satılabilir miktar; fiziksel stoktan açık rezervasyonlar, kalite kontrolündeki ürünler, hasarlı miktar, mağaza veya depo güvenlik payı ve diğer kanallara ayrılan kontenjan düşülerek hesaplanabilir. Formül her işletmede aynı değildir; depo, ürün grubu, kampanya ve pazaryeri bazında tanımlanabilmelidir.

Örneğin ERP’de 20 adet görünen bir ürünün 4 adedi hazırlanmakta olan siparişlere rezerve, 3 adedi güvenlik payı olabilir. Pazaryerlerine toplam 13 adet açmak yerine kanal öncelikleri ve paylaşım politikası uygulanmalıdır. Bütün kanallara 13 göstermek, eş zamanlı satışlarda aşırı satış riskini sürdürür. Merkezi rezervasyon servisi veya kanal kotası bu riski yönetir.

Stok olayları aynı ürün ve depo anahtarı için sıralı ele alınmalıdır. “Stok 8 oldu” mesajından sonra üretilen “stok 6 oldu” mesajı ağ gecikmesi nedeniyle önce işlenirse eski olay yeni değerin üzerine yazabilir. Mesajlara monoton sürüm, ERP hareket numarası veya olay zamanı eklenmeli; tüketici daha eski sürümü reddetmelidir. Çok sık değişen ürünlerde her hareketi göndermek yerine kısa birleştirme penceresiyle yalnızca güncel son değeri aktarmak API yükünü azaltabilir. Ancak sipariş rezervasyonu gibi kritik hareketler geciktirilmemelidir.

Ürün kodu, barkod ve kanal eşlemeleri de stok doğruluğunun parçasıdır. Merkezi ürün verisinin nasıl düzenleneceği konusunda PIM ve çok kanallı ürün bilgisi yönetimi yaklaşımı, stok mesajının doğru pazaryeri ilanıyla eşleşmesini destekler.

Fiyat senkronizasyonunda kural sırası ve geçerlilik zamanı

Fiyat, tek bir sayısal alan olarak aktarılmamalıdır. Liste fiyatı, para birimi, KDV durumu, müşteri veya kanal komisyonu, kampanya indirimi, minimum marj, yuvarlama kuralı ve başlangıç-bitiş zamanı birlikte değerlendirilmelidir. Entegrasyon katmanı hangi kaynağın esas olduğunu ve kurallar çakıştığında hangi sıranın uygulanacağını açıkça bilmelidir.

Sağlıklı bir fiyat akışı; ERP taban fiyatını alır, kanal kuralını uygular, minimum ve maksimum sınırları doğrular, geçerlilik zamanını kontrol eder ve oluşan fiyatı sürümlü biçimde kuyruğa yazar. İşlem anında kullanılan kurallar da kaydedilmelidir. Böylece ekip yalnızca “fiyat 849 TL gönderildi” bilgisini değil, bu sonucun hangi taban fiyat, iskonto ve yuvarlama adımlarından üretildiğini görebilir.

Toplu fiyat güncellemeleri için ayrı öncelik ve kapasite politikası gerekir. Yeni kampanyanın belirli saatte başlaması gerekiyorsa mesajların son anda oluşturulması risklidir. Güncellemeler önceden hazırlanabilir, doğrulanabilir ve geçerlilik anında kontrollü olarak serbest bırakılabilir. Kritik bir yanlış fiyat tespit edildiğinde ilgili ürün veya mağaza akışı durdurulabilmeli; onaylı düzeltme, bekleyen eski mesajların önüne geçebilmelidir.

Siparişin pazaryerinden ERP’ye güvenli akışı

Sipariş akışında hedef, pazaryerinin bildirimini almak değil, siparişin ERP tarafından bir kez kabul edildiğini ve operasyonun devam edebildiğini kanıtlamaktır. Webhook kaçırılabilir, aynı bildirim tekrar gelebilir veya sorgu servisi aynı siparişi yeniden döndürebilir. Bu nedenle webhook ve periyodik mutabakat birlikte kullanılabilir; her iki kaynaktan gelen kayıt aynı sipariş anahtarı altında birleştirilir.

Güvenli işlem hattında sipariş önce ham haliyle değiştirilemez bir giriş kaydına alınır. İmza ve mağaza yetkisi doğrulanır; pazaryeri ürün kodları şirket içi ürünlerle eşleştirilir; adres, vergi, ödeme ve teslimat alanları kontrol edilir. Ardından sipariş ERP’ye gönderilir, ERP kabul numarası kaydedilir ve durum pazaryerine yansıtılır. Başarılı kabul kanıtlanmadan mesaj tamamlanmış sayılmamalıdır.

Aynı isteğin ağ hatası nedeniyle tekrarlanması, ikinci sipariş yaratmamalıdır. Her sipariş için pazaryeri, mağaza ve dış sipariş numarasından idempotency anahtarı üretilebilir. Tüketici bu anahtarla daha önce tamamlanan işlemi bulup mevcut sonucu döndürür. Stripe’ın idempotent istek yaklaşımı da güvenli yeniden denemelerde benzersiz anahtar kullanarak aynı işlemin yanlışlıkla iki kez uygulanmasını engelleme ilkesini açıklar.

Uçtan uca senkronizasyon akışı nasıl kurulmalıdır?

Ortak mimari stok, fiyat ve sipariş için aynı kontrol omurgasını kullanabilir; ancak her veri türünün kuyruğu, önceliği ve hata politikası ayrılmalıdır. Siparişlerin gecikme toleransı ile katalog fiyatlarının toplu işlenme şekli aynı değildir. Tek büyük kuyruk, yoğun stok trafiğinin siparişleri bekletmesine neden olabilir.

1. Olayı kabul etme ve kalıcılaştırma

Kaynak sistemden alınan olay önce doğrulanır ve kaybolmayacağı kalıcı bir kayıt alanına yazılır. Kaynak, işletme, kanal, varlık anahtarı ve korelasyon kimliği eklenir. Kabul yanıtı ancak bu güvenli kayıt tamamlandığında verilmelidir.

2. Normalizasyon ve iş kuralı

ERP ile pazaryerlerinin farklı alanları ortak veri modeline dönüştürülür. Stokta güvenlik payı, fiyatta marj ve kampanya, siparişte ürün eşleme ve zorunlu alan kontrolleri burada uygulanır. Geçersiz veri teknik yeniden denemeye değil, iş kuralı incelemesine yönlendirilir.

3. Kuyruklama ve önceliklendirme

Mesaj uygun kanal ve işlem türü kuyruğuna alınır. Acil stok sıfırlama, yeni sipariş ve yanlış fiyat düzeltmesi gibi işler öncelikli olabilir. Aynı ürün veya siparişe ait olaylarda bölümleme anahtarı kullanılarak gerekli sıra korunur.

4. Hedefe kontrollü gönderim

Worker servisleri hedef API’nin hız sınırına göre mesaj tüketir. Eşzamanlı çalışan sayısı ve saniyedeki istek miktarı kanal bazında ayarlanır. Hedef sistem yavaşladığında kuyruk büyüyebilir; fakat kontrollü tüketim sayesinde sorun diğer sistemlere zincirleme taşınmaz.

5. Sonuç, mutabakat ve geri bildirim

Başarı yanıtı, dış sistem kayıt numarası ve işlenen sürüm saklanır. Belirsiz yanıtlar daha sonra hedef sistemden sorgulanır; doğrudan yeniden gönderilmez. Planlı mutabakat işleri ERP ve pazaryeri durumlarını karşılaştırarak kaçırılmış ya da farklı kalmış kayıtları operasyon kuyruğuna çıkarır.

Yeniden deneme, idempotency ve ölü mektup kuyruğu

Her hata aynı biçimde yeniden denenmemelidir. Ağ kesintisi, zaman aşımı, HTTP 429 veya geçici 5xx yanıtı artan bekleme süreleri ve rastgele sapma eklenerek tekrar denenebilir. Geçersiz ürün kodu, kapalı mağaza, eksik adres veya yetki hatası ise insan müdahalesi ya da veri düzeltmesi gerektirir. Bu ayrım yapılmazsa çözülemeyen mesajlar sistemi sürekli meşgul eder.

Deneme sayısı sınırlı olmalı; sınırı aşan mesajlar ölü mektup kuyruğuna taşınmalıdır. Amazon SQS görünürlük zaman aşımı rehberi, işlenen mesajın geçici olarak diğer tüketicilerden gizlenmesini, tamamlanamayan mesajın yeniden görünmesini ve sürekli başarısız kayıtların DLQ ile ayrıştırılmasını açıklar. Görünürlük süresi gerçek işlem süresinden kısa olursa iki worker aynı işi üstlenebilir; gereğinden uzun olursa hata sonrası toparlanma gecikir.

Idempotency yalnızca siparişte değil stok ve fiyat güncellemelerinde de uygulanmalıdır. Mesaj kimliği, varlık anahtarı ve sürüm numarası birlikte kontrol edilerek aynı olayın ikinci kez yan etki üretmesi önlenebilir. İşlem sonucu ile idempotency kaydının farklı anlarda yazılması yeni bir hata aralığı oluşturacağından mümkün olduğunda atomik kayıt veya transactional outbox yaklaşımı kullanılmalıdır.

Operasyon ekranında hangi kontroller bulunmalıdır?

Teknik olarak çalışan fakat ekiplerin göremediği entegrasyon yönetilebilir değildir. Operasyon ekranı; kuyruk derinliği, en eski mesajın yaşı, başarı ve hata oranı, yeniden deneme sayısı, kanal gecikmesi ve DLQ büyüklüğünü göstermelidir. Filtreler mağaza, pazaryeri, işlem türü, ürün, sipariş ve tarih bazında aramaya izin vermelidir.

Yetkili kullanıcı mesajın zaman çizelgesini, maskelenmiş istek ve yanıt özetini, uygulanan iş kurallarını ve son hata nedenini görebilmelidir. “Tekrar dene”, “düzeltip yeniden işle”, “iptal et” ve “akışı durdur” işlemleri rol bazlı yetkilendirilmelidir. Özellikle fiyat ve sipariş müdahalelerinde çift onay gerekebilir. Her manuel işlem kullanıcı, zaman, eski değer, yeni değer ve gerekçe ile denetim izine yazılmalıdır.

Alarm yalnızca hata sayısına bağlanmamalıdır. Hata görünmese bile kuyruktaki en eski siparişin yaşı hedef süreyi aşabilir veya stok güncellemeleri belirli bir mağazada birikebilir. Bu nedenle servis seviyesi göstergeleri iş sonucuna göre tanımlanmalıdır: siparişin ERP’ye kabul süresi, stok olayının kanala yansıma gecikmesi ve fiyat güncellemesinin doğrulanma süresi gibi.

Veri akışlarına göre temel kontrol noktaları

Ortak buffer altyapısı kullanılsa da stok, fiyat ve siparişin iş riski farklıdır. Mimari kararlar aşağıdaki kontrol alanları etrafında özelleştirilmelidir.

Pazaryeri entegrasyon projesi nasıl planlanır?

Çalışmaya API uç noktalarını listeleyerek değil, gerçek operasyon akışını çıkararak başlanmalıdır. Hangi sistem hangi verinin sahibidir, stok ne zaman rezerve edilir, fiyatı kim onaylar, sipariş hangi koşulda ERP’ye kabul edilmiş sayılır ve kesinti sırasında ekip ne yapar soruları yanıtlanmalıdır. Ardından hacim, yoğun saat, API kotaları, kabul edilebilir gecikme ve veri saklama gereksinimleri ölçülür.

İlk tasarımda ortak veri modeli, kuyruk ayrımları, mesaj şeması, sıralama anahtarları, yeniden deneme matrisi, idempotency politikası ve yetki modeli belgelenmelidir. Kampanya yoğunluğu, pazaryeri kesintisi, gecikmiş mesaj, yinelenen webhook, sıra dışı olay ve ERP bakım senaryoları test edilmelidir. Canlıya geçişte kanal bazlı kademeli açılış, karşılaştırmalı mutabakat ve geri dönüş planı riski azaltır.

Kumsal Ajans, pazaryeri entegrasyonunu hazır bir API bağlantısından ibaret görmeden ERP, e-ticaret ve operasyon ihtiyaçlarına göre projeye özel web yazılımı ve senkronizasyon mimarisi olarak ele alır. Veri akışlarınızı ve operasyon kurallarınızı birlikte analiz ederek markanıza özel, güvenli ve ölçeklenebilir bir yapı planlamak için Kumsal Ajans ile iletişime geçin.