Gerçek Zamanlı Envanter Senkronizasyonu Mimarisi: Web Kancaları, Kuyruklar ve Çakışma Çözümü

Tek bir aşırı satışın doğrudan maliyetleri ortalama 47 ABD dolarıdır - geri ödeme işlemi, müşteri hizmetleri süresi, pazardaki kusur cezaları ve itibar kaybı. Dört kanal üzerinden günde 500 sipariş işleyen orta ölçekli bir satıcı için %1'lik fazla satış oranı bile yıllık 70.000 $'a mal oluyor. Temel neden neredeyse her zaman envanter senkronizasyonu gecikmesidir.

Bu gönderi, gerçek zamanlı envanter senkronizasyonunun arkasındaki mimariyi ayrıntılarıyla ele alıyor: olayların nasıl yayıldığı, kuyrukların trafik artışlarını nasıl absorbe ettiği ve çatışma çözümünün, hem marjları hem de pazardaki konumu aşındıran aşırı satışları nasıl önlediği.

Önemli Çıkarımlar

• Web kancaları saniyenin altında bildirim sunar ancak aynı yetkiye sahip işleyiciler ve doğrulama gerektirir
• Mesaj kuyrukları beslemeyi işlemeden ayırır; pazar olaylarını asla eşzamanlı olarak işlemez
• Anlaşmazlıkların çözümü, mutlak miktar üzerine yazma yerine, delta tabanlı güncellemelere sahip merkezi bir envanter defteri gerektirir
• Web kancaları birincil senkronizasyon yönteminiz olsa bile, yoklama bir mutabakat mekanizması olarak önemini koruyor

---

Senkronizasyon Yöntemleri Karşılaştırıldı

Mimariye dalmadan önce, envanteri kanallar arasında senkronize tutmaya yönelik üç temel yaklaşımın anlaşılmasına yardımcı olur.

Üretim önerisi karmadır. Gerçek zamanlı güncellemeler için web kancalarını ve periyodik mutabakat için yoklamayı kullanın. Bu size, planlanmış doğrulamanın güvenilirliği ile olay odaklı mimarinin hızını sunar.

---

Envanter için Olay Odaklı Mimari

Olay odaklı bir envanter sistemi, stoğu etkileyen her eylemi bir olay olarak ele alır: satış, iade, satınalma siparişi girişi, depo transferi, manuel ayarlama. Bu olaylar bir mesaj kuyruğunda yayınlanır ve merkezi envanter defterini güncelleyen ve değişiklikleri tüm kanallara yayan çalışanlar tarafından tüketilir.

Etkinlik Akışı

1. Olay kaynağı bir envanter olayı yayınlar (ör. Shopify bir orders/create web kancasını başlatır)
2. Besleme uç noktası etkinliği alır, orijinalliği doğrular ve mesaj kuyruğunda yayınlar
3. İşleme çalışanı olayı tüketir ve ERP'deki merkezi envanter defterini günceller
4. Yayılım çalışanları güncellenen miktarı okur ve diğer tüm kanallara aktarır

Bu mimarinin üç kritik özelliği vardır:

• Eşzamansız: Besleme uç noktası web kancasına hemen yanıt verir (HTTP 200) ve daha sonra işler. Bu, web kancası zaman aşımlarını önler.
• Dayanıklı: Mesaj kuyruğu olaylara devam eder. Bir çalışanın kaza yapması durumunda etkinlik yeniden iletilir.
• Ölçeklenebilir: Besleme katmanını değiştirmeden daha yüksek aktarım hızının üstesinden gelmek için çalışanlar ekleyebilirsiniz.

---

Web Kancaları: Tasarım ve Tuzaklar

Çoğu modern e-ticaret platformu, envanterle ilgili etkinlikler için web kancalarını destekler. Shopify inventory_levels/update gönderir, Amazon SP-API sipariş ve envanter değişiklikleri için bildirimler sunar ve WooCommerce woocommerce_product_set_stock'i başlatır.

Web Kancası Doğrulaması

Her webhook işleyicisinin isteğin gerçek olduğunu doğrulaması gerekir. Sahte webhook verileri gerçek bir saldırı vektörüdür; sisteminizde envanter değişikliklerini tetikleyebilen bir saldırgan, istediği zaman aşırı satışlara veya stok tükenmelerine neden olabilir.

• Shopify: X-Shopify-Hmac-SHA256 başlığındaki HMAC-SHA256 imzası, uygulama sırrınızla doğrulandı
• Amazon SP-API: SNS mesaj imzası doğrulaması
• WooCommerce: X-WC-Webhook-Signature başlığındaki web kancası sırrı

İşlemeden önce daima doğrulayın. Geliştirme aşamasında doğrulamayı asla atlamayın; bu, üretimde güvenlik açığı haline gelen tek kısayoldur.

İdempotans

Web kancaları tam olarak bir kez değil, en az bir kez teslim edilir. Ağ sorunları, yeniden denemeler ve platform tuhaflıkları, işleyicinizin zaman zaman yinelenen olaylar alacağı anlamına gelir. İşleyiciniz bağımsız olmalıdır; aynı olayı iki kez işlemek, onu bir kez işlemekle aynı sonucu vermelidir.

İdempotency için uygulama modelleri:

• Idempotency anahtarı: Webhook kimliğini (veya yükün karmasını) Redis'te bir TTL ile saklayın. Anahtar mevcutsa işlemeyi atlayın.
• Delta işlemleri: Hiçbir zaman webhook verilerinden mutlak miktarlar ayarlamayın. Bunun yerine, yinelenen bir uygulamanın tespit edilebilmesi için deltayı uygulayın (örneğin, "1 azalt").
• Veritabanı kısıtlamaları: Yinelenen sipariş içe aktarmalarını önlemek için harici olay kimliklerinde benzersiz kısıtlamalar kullanın.

// Pseudocode: idempotent webhook handler
function handleInventoryWebhook(payload) {
  const eventId = payload.id
  const exists = await redis.set(eventId, '1', 'NX', 'EX', 86400)
  if (!exists) return // duplicate, skip

  await queue.publish('inventory.update', {
    sku: payload.sku,
    delta: payload.quantity_change,
    source: payload.source,
    eventId: eventId
  })
}

Web Kancası Arızasını İşleme

Uç noktanız 2xx olmayan bir duruma döndüğünde, pazaryerleri üstel geri çekilmeyle yeniden dener. Shopify 48 saat içinde 19 defaya kadar yeniden deneme yapar. Amazon 3 güne kadar yeniden dener. Sisteminiz bakım nedeniyle kapalıysa olaylar pazar tarafında sıraya girer ve tekrar çevrimiçi olduğunuzda bir patlama halinde gelir.

Mimarinizin bu patlamayı karşılaması gerekiyor. Bu, mesaj kuyruğu kullanmanın başka bir nedenidir; kuyruk patlamayı emer ve çalışanlar olayları sürdürülebilir bir hızda işler.

---

Envanter Etkinlikleri için Mesaj Kuyrukları

Mesaj kuyruğu, envanter senkronizasyon mimarinizin omurgasıdır. Olay alımını işlemeden ayırır, dayanıklılık sağlar ve bağımsız ölçeklendirmeye olanak tanır.

Kuyruk Teknolojisi Seçimi

Odoo tabanlı entegrasyonlar için ECOSIRE, varsayılan olarak BullMQ'yu (Redis üzerine kurulu) kullanır. İş önceliklendirme, ertelenen işler, hız sınırlama ve izleme için bir kontrol paneli sağlar; bunların tümü envanter senkronizasyonu için kritik öneme sahiptir. Odoo dağıtımları önbelleğe alma için zaten Redis'i kullandığından kurulum minimum düzeydedir.

Kuyruk Tasarım Modelleri

Konuya dayalı yönlendirme: Farklı etkinlik türleri için ayrı kuyruklar. Envanter etkinlikleri inventory.updates'ye gider, sipariş etkinlikleri orders.created'ye gider, fiyat değişiklikleri products.price_updated olarak değişir. Bu, çalışanları bağımsız olarak ölçeklendirmenize olanak tanır; ürün güncellemeleri kendi hızlarında işlenirken envanter senkronizasyonu yoğun saatlerde daha fazla çalışan alır.

Öncelik sıraları: Tüm envanter güncellemeleri eşit değildir. Bir satış (azalış), bir satın alma makbuzundan (artış) daha acildir çünkü aşırı satışların anında finansal etkisi vardır. Azalan olaylara daha yüksek öncelik atayın.

Ölü mektup kuyruğu (DLQ): N yeniden denemeden sonra işlenemeyen olaylar, manuel inceleme için bir DLQ'ya taşınır. Bu, zehirli mesajların tüm kuyruğu engellemesini önler. DLQ girişlerini günlük olarak inceleyin; bunlar genellikle veri eşleme sorunlarını veya API değişikliklerini ortaya çıkarır.

---

Çatışma Çözümü Stratejileri

Envanter senkronizasyonundaki en zor sorun eş zamanlı güncellemelerdir. İki müşteri aynı anda bir ürünün son adedini farklı kanallardan satın alıyor. Çatışma çözümü olmadan, her iki sipariş de başarılı olur ve siz fazla satış yaparsınız.

Merkezi Defter Modeli

En güvenilir yaklaşım, ERP'nizde gerçeğin tek kaynağı olan merkezi bir envanter defteridir. Kanallar satışları rapor eder ve merkez mevcut miktarı yeniden hesaplar.

Kural: Kanallar hiçbir zaman mutlak miktarları ayarlamaz. Deltaları (satışlar, iadeler, ayarlamalar) rapor ederler ve merkezi defter yeni mevcut miktarı hesaplar ve bunu yayar.

Bu, iki kanalın aynı anda aynı miktarı okuduğu, bunu yerel olarak azalttığı ve aynı değeri geri yazdığı (düşüşlerden birini kaybederek) yarış koşulları sınıfını ortadan kaldırır.

Rezervasyon Sistemi

Yüksek hızlı SKU'lar için delta tabanlı senkronizasyon bile yeterince hızlı değildir. Bir rezervasyon sistemi, satış hızına ve tampon kurallarına göre envanteri kanallara önceden tahsis eder.

Güvenlik arabellekleri senkronizasyon gecikmesine karşı koruma sağlar. Amazon, senkronizasyonun yayılması için gereken sürede 2 birim satarsa ​​arabellek farkı emer.

Nihai Tutarlılık

Çok kanallı envanter sonuçta tutarlı bir sistemdir. Herhangi bir milisaniyede kanal miktarları merkezi defterle tam olarak eşleşmeyebilir. Amaç, tutarlılık penceresini (bir değişiklik ile tam yayılma arasındaki süre) en aza indirmek ve bu pencere sırasındaki riski güvenlik tamponlarıyla yönetmektir.

Tutarlılık pencerelerini önceliğe göre hedefleyin:

• Satışlar (azalışlar): 5 saniyeden az
• Geri dönüşler (artışlar): 60 saniyeden az
• Ayarlamalar: 5 dakikadan az
• Tam mutabakat: Her 6-12 saatte bir

---

Uzlaşma Olarak Oylama

Web kancası öncelikli mimaride bile yoklama hayati önem taşıyor. Web kancaları kaybolabilir, gecikebilir veya kullanım dışı kalabilir. Mutabakat işi bir zamanlamaya göre çalışır, her kanaldan mevcut durumu alır ve bunu merkezi defterle karşılaştırır.

Tutarsızlıklar işaretlenir ve küçük farklar (3 birimden az) için otomatik olarak düzeltilir veya daha büyük boşluklar için manuel inceleme için iletilir. Bu şunu yakalar:

• Pazardaki kesintiler nedeniyle kaçırılan web kancaları
• Doğrudan pazar kontrol panellerinde yapılan manuel ayarlamalar
• Miktar hesaplamalarında yuvarlama hataları
• Sistem bakım pencereleri sırasında kaybedilen olaylar

İzleme ve arıza tespitine ilişkin daha geniş bir bakış açısı için bkz. Entegrasyon İzleme: Senkronizasyon Arızalarının Tespiti.

---

Ölçeklendirmeyle İlgili Hususlar

Sipariş hacmi büyüdükçe envanter senkronizasyon mimariniz yeni zorluklarla karşı karşıya kalır.

Oran Sınırı Yönetimi

Her pazaryeri API'sinin hız sınırları vardır. Bir depo girişinden sonra Amazon'daki 5.000 SKU'daki envanteri güncellemeniz gerektiğinde, aynı anda 5.000 API çağrısını başlatamazsınız. Hızı sınırlı bir çalışan kuyruğu, güncellemeleri izin verilen maksimum hızda damlatır (Amazon SP-API: envanter yayınları için 10 istek/saniye).

Toplu ve Gerçek Zamanlı Değişimler

10.000 SKU'yu aşan kataloglar için tam katalog senkronizasyonu, gerçek zamanlı bireysel güncellemelerden toplu feed gönderimlerine geçiş yapar. Amazon'un envanter feed'leri tek bir API çağrısında binlerce SKU'yu işler. Shopify'ın toplu işlemler API'si büyük ölçekli güncellemeleri verimli bir şekilde yönetir.

Mimari her iki modeli de desteklemelidir: yüksek hızlı SKU'lar için gerçek zamanlı (satış hacmine göre ilk %20) ve uzun kuyruk için toplu.

Coğrafi Dağılım

Bölgeler arasında (ABD, AB, APAC) satış yapmak gecikme zorlukları doğurur. ABD-Doğu'daki bir Redis örneği, AB tabanlı platformlardan webhook işlemeye 200 ms'lik gidiş-dönüş süresi ekler. Küresel dağıtımlar için, merkezi defterin bölgeler arası çoğaltılmasıyla bölgesel işlemeyi düşünün.

Çok kanallı mimari tasarımı hakkında daha fazla bilgi için şu sütun gönderisine bakın: The Ultimate e-Commerce Integration Guide.

---

Sıkça Sorulan Sorular

Aşırı satışları önlemek için envanter senkronizasyonu ne kadar hızlı olmalıdır?

Çoğu satıcı için 30 saniyenin altındaki senkronizasyon, aşırı satışların büyük çoğunluğunu önler. Risk penceresi, bir kanaldaki satış ile envanter güncellemesinin diğer kanallara ulaşması arasındaki süredir. 30 saniyelik bir pencere ve günde 500 siparişle aynı SKU'da eş zamanlı satış olasılığı %0,1'in altındadır. Yüksek hızlı SKU'lar (SKU başına günde 100'den fazla satış), 5 saniyeden kısa senkronizasyon veya rezervasyon sisteminden yararlanır.

Web kancaları yerine yoklamayı kullanabilir miyim?

Yapabilirsiniz, ancak 5 dakikalık aralıklarla yoklama yapmak, envanterinizin her kanalda potansiyel olarak 5 dakikalık bayat olduğu anlamına gelir. Orta dereceli sipariş hacimlerinde bu, aşırı satışları garanti eder. Anket, bir geri dönüş ve mutabakat mekanizması olarak çalışır, ancak web kancaları, onları destekleyen herhangi bir kanal için birincil senkronizasyon tetikleyiciniz olmalıdır.

Odoo ile hangi mesaj kuyruğunu kullanmalıyım?

BullMQ (Redis üzerine kurulu), Odoo dağıtımları için önerilen seçimdir. Odoo altyapınız önbelleğe alma için zaten Redis'i içeriyor, dolayısıyla yeni bir altyapıya gerek yok. BullMQ iş önceliklendirme, hız sınırlama, ertelenen işler ve bir izleme panosu sağlar. Günde 100.000 olayı aşan kurumsal dağıtımlar için RabbitMQ veya Kafka'yı düşünün.

Pazar yerindeki kesintiler sırasında envanter senkronizasyonunu nasıl halledebilirim?

Etkilenen kanal için tüm giden güncellemeleri sıraya alın. Pazar yeri tekrar çevrimiçi olduğunda sırayı sırayla boşaltın. Gelen etkinlikler (pazaryerinden gelen siparişler) için pazaryeri, düzeldiğinde web kancalarını yeniden oynatacaktır. İdempotency katmanınız, yinelenen işlemlerin gerçekleşmemesini sağlar. Kesinti penceresini kapatmak için güvenlik tamponlarını koruyun.

İdeal uzlaşma sıklığı nedir?

Etkin SKU'lar için her 6 ila 12 saatte bir, kataloğun tamamı için ise 24 saatte bir tam mutabakat gerçekleştirin. Daha sık mutabakat, yavaş hareket eden SKU'lardaki API kotasını boşa harcar. Daha az sıklıkta uzlaşma, sürüklenmenin birikmesine izin verir. Aşırı satış oranınıza göre ayarlama yapın; sürüklenmeyle ilgili sorunlar görüyorsanız sıklığı artırın.

---

Sırada Ne Var

Envanter senkronizasyonu, çok kanallı e-ticaretin teknik temelidir ancak tek başına mevcut değildir. Envanteriniz kanallar arasında doğru olduktan sonra, bir sonraki adım siparişlerin sipariş karşılama ağınız üzerinden akışını optimize etmektir.

Odoo için üretime hazır envanter senkronizasyon bağlayıcıları için ECOSIRE entegrasyon hizmetlerini keşfedin veya özel mimari gereksinimlerinizi görüşmek için ekibimizle iletişime geçin.

---

ECOSIRE tarafından yayınlandı — işletmelerin Odoo ERP, Shopify eCommerce ve OpenClaw AI genelinde yapay zeka destekli çözümlerle ölçeklenmesine yardımcı oluyor.