TL;DR: «Gerçek zamanlı stok senkronu» kulağa kusursuz gelir ama mühendislik açısından çoğu zaman bir yalandır. Pazaryeri API'leri gönderebileceğiniz istek sayısını sınırlar (rate limit veya throttling); bu yüzden «anlık» dediğiniz güncelleme pratikte her zaman biraz gecikmelidir. Normal günlerde bu gecikme zararsızdır çünkü satış hızı düşüktür. Ama en kötü an tam da en kritik andır: kampanya ya da yüksek satış hızı anında hem güncelleme ihtiyacı patlar hem de istekler limite dayanıp kuyruğa takılır. Sonuç bayat stok, oradan da aşırı satış veya gereksiz stoksuz görünmedir. Çözüm gerçek zamanı kovalamak değil; tampon stok ve öncelik kuyruğuyla bu boşluğu akıllıca köprülemektir.
Gerçek zamanlı vaadinin altındaki fizik
Pazarlama dilinde «anlık senkron» bir özellik gibi sunulur, sanki stok değiştiği an her kanalda eşzamanlı güncellenir. Oysa altta yatan mekanizma bunu fiziksel olarak imkansız kılar. Sisteminizle pazaryeri arasındaki her iletişim bir API çağrısıdır ve bu çağrılar ne anında ne de sınırsızdır. Her güncelleme ağ üzerinden gider, pazaryerinin sunucusunda işlenir ve onaylanır; bu döngü milisaniyeler değil çoğu zaman saniyeler alır.
Üstüne pazaryeri size «belli bir hızın üstünde istek kabul etmem» der. Yani stoğunuz saniyede on kez değişse bile, pazaryerine bunu saniyede on kez bildiremezsiniz. Gerçek zamanlılık bu yüzden bir vaat değil, bir yaklaşımdır; ne kadar iyi mühendislik yaparsanız o boşluğu o kadar daraltırsınız ama asla sıfırlayamazsınız.
Throttling tam olarak nedir
Throttling, bir API'nin belirli bir zaman penceresinde kabul ettiği istek sayısını sınırlamasıdır. Pazaryeri bunu keyfinden değil, kendi altyapısını korumak için yapar: milyonlarca satıcı aynı anda sınırsız istek gönderse sistem çöker. Bu yüzden her satıcıya saniyede ya da dakikada bir kota tanınır. Kotayı aştığınızda pazaryeri isteğinizi reddeder ya da kuyruğa alır ve «yavaşla» sinyali döndürür.
Bunun stok yönetimine yansıması nettir: güncelleme göndermek istediğinizde her zaman gönderemezsiniz. Limite dayandığınızda güncellemeleriniz beklemeye geçer. O bekleme süresince pazaryeri eski, yani bayat stok bilgisini göstermeye devam eder. Müşteri o bayat bilgiye bakarak sipariş verir. İşte aşırı satışın ve yanlış stok görünümünün API tarafındaki kaynağı budur. Önemli olan şu: bu gecikme bir arıza değil, sistemin tasarımı gereği oluşan normal bir davranıştır; dolayısıyla onu bir hata gibi düzeltmeye çalışmak değil, varlığını kabul edip etkilerini yönetmek doğru yaklaşımdır.
Neden en kötü an, en kritik andır
Throttling'in zalim ironisi zamanlamasındadır. Limit, satışın yavaş olduğu sakin günlerde hiç hissedilmez; az satış, az güncelleme, bol kota. Ama tam da işlerin kızıştığı anda devreye girer ve sizi en savunmasız yerinizden vurur.
Kampanya gününü düşünün. O gün iki şey aynı anda patlar:
- Güncelleme ihtiyacı artar: Hızlı satış, stoğun saniyeler içinde değişmesi demektir; pazaryerine sürekli yeni sayı bildirmeniz gerekir.
- İstek hacmi limite dayanır: Aynı anda sipariş çekme, fiyat güncelleme ve stok bildirme istekleri kotayı doldurur.
Bu iki eğri tam da en kötü anda kesişir. Stok en hızlı değişirken güncellemeniz kuyruğa takılır. Pazaryeri en yoğun trafikte en bayat sayıyı gösterir. Sonuç: gerçekte tükenmiş ürün hâlâ «stokta» görünür ve aşırı satış doğar; ya da tam tersi, güvenli oynayıp fazla düşülen stok ürünü gereksiz «tükendi» gösterir ve kampanyanın zirvesinde satış kaçırırsınız. Her iki yönde de en pahalı hatayı en pahalı anda yaparsınız.
Çözüm gerçek zamanı kovalamak değil
Çoğu satıcının içgüdüsü «daha hızlı senkron edeyim, gecikmeyi kapatırım» olur. Bu, throttling'in fiziğini yok saymaktır; ne kadar hızlandırırsanız limite o kadar erken çarparsınız. Doğru yaklaşım gecikmeyi yok etmeye çalışmak değil, onu kabul edip köprülemektir. İki temel araç var: tampon stok ve öncelik kuyruğu. İkisi de gecikmeyi yok etmeye değil, ona rağmen güvenli kalmaya hizmet eder.
Bunlardan ilki tampon stoktur. Tampon (emniyet) stok, pazaryerinde gerçek stoğunuzun bir miktar altını göstermektir. Mantığı basittir: senkronun yetişemediği o kritik saniyelerde, gösterdiğiniz sayı ile gerçek sayı arasındaki fark sizi aşırı satıştan korur. Deponuzda 100 varsa pazaryerinde 95 gösterirseniz, güncelleme kuyruğa takılı kalsa bile o 5 adetlik fark bayat verinin yol açacağı hasarı yutar.
Tampon sabit değildir; satış hızıyla orantılı olmalıdır. Yavaş satan üründe küçük bir pay yeter çünkü senkron rahatça yetişir. Ama kampanyada dakikada onlarca satan üründe payı geçici olarak büyütmek gerekir; çünkü o üründe gecikme penceresi içinde çok daha fazla satış gerçekleşir. Kural: ürün ne kadar hızlı dönüyorsa tampon o kadar kalın olmalı.
İkinci araç öncelik kuyruğudur. API kotanız sınırlıysa, onu her ürüne eşit dağıtmak en kötü stratejidir. Beş bin ürünü eşit sıklıkta güncellemeye çalışırsanız, dakikada elli satan kritik ürününüz, yılda bir satan bir kalemle aynı kuyrukta bekler. Çözüm öncelik kuyruğudur: güncelleme kotasını önce en çok riske maruz ürünlere ayırmak.
- Hızlı dönenler önce: En çok satan ve stoğu hızla değişen ürünler kuyruğun başına alınır; bayat veri en çok onlarda zarar verir.
- Kritik stok seviyesi önce: Tükenmeye yakın ürünler önceliklendirilmeli; bol stoklu bir ürünün bir saniye geç güncellenmesi önemsizdir.
- Durağanlar seyrek: Stoğu nadiren değişen ürünler düşük sıklıkta güncellenerek kota tasarruf edilir.
Bu mantığı elle kurmak zordur; çok kanallı stok ve sipariş yazılımları tam bu işi yapar. Tekciro gibi araçlar güncellemeleri kör bir döngüde değil, öncelik ve risk sırasına göre yöneterek kıt API kotasını en çok ihtiyaç duyulan yere kanalize eder. Böylece kampanya gününde kuyruğa en az kritik ürünler takılır.
Bir senaryo: köprülenmiş kampanya
Kurgusal bir örnek. Bir kozmetik satıcısı, geçmiş kampanyalarda en çok satan üründe sürekli aşırı satış yaşıyor ve her seferinde iptal ediyor. Bir sonraki kampanyaya farklı hazırlanıyor: o ürün için tamponu normalin belirgin üstüne çıkarıyor, güncelleme önceliğini en hızlı satan birkaç ürüne kilitliyor ve kritik stok eşiğinde ürünü otomatik pasife alacak bir kural koyuyor. Kampanya günü API limiti yine doluyor, güncellemeler yine gecikiyor; ama bu kez tampon gecikmeyi yutuyor, öncelik kuyruğu kritik ürünü en güncel tutuyor. Aşırı satış neredeyse sıfıra iniyor. Hiçbir senkron mucizesi olmadı; sadece gecikme yok edilmeye değil, köprülenmeye çalışıldı.
Disiplinle birlikte yürümek
Tampon ve öncelik kuyruğu, ancak altlarındaki stok verisi doğruysa işe yarar. Sistemdeki sayı baştan yanlışsa, en akıllı tampon bile yanlış sayının üstüne kurulur. Bu yüzden düzenli sayım vazgeçilmezdir; dönemsel sayım disiplini, köprülediğiniz boşluğun sağlam bir zemine oturmasını sağlar. Aynı şekilde tamponu ve güncelleme önceliğini doğru ayarlamak için hangi ürünün ne hızda döndüğünü bilmek gerekir; envanter devir hızı metriği, hangi ürüne kalın tampon ve yüksek öncelik vereceğinizi söyleyen pusuladır. Hızlı dönen ürün daha kalın yastık ve daha yüksek sıra; yavaş dönen ürün ince pay ve düşük öncelik ister.
Toplu güncelleme ve akıllı gruplama
Kıt API kotasını korumanın bir başka anahtarı, güncellemeleri akıllıca gruplamaktır. Her stok değişikliğini ayrı bir istekle göndermek kotayı en savurgan biçimde harcar; oysa pazaryeri API'lerinin çoğu, birden çok ürünü tek bir istekte güncellemeye izin veren toplu (batch) işlemleri destekler. Yüz ayrı ürünü yüz ayrı çağrı yerine birkaç toplu çağrıyla bildirmek, aynı kota içinde çok daha fazla iş yapmanızı sağlar.
Ancak toplu güncelleme tek başına yeterli değildir; doğru zamanlama da gerekir. İki tamamlayıcı taktik öne çıkar:
- Değişiklik biriktirme: Saniyeler içinde defalarca değişen bir ürünün her ara değerini göndermek anlamsızdır; kısa bir pencerede biriken değişiklikleri tek bir nihai değere indirip öyle göndermek hem kota hem doğruluk açısından üstündür.
- Sakin saatleri kullanma: Acil olmayan toplu güncellemeleri trafiğin düşük olduğu saatlere kaydırmak, kampanya ve yoğun saatlerde kotayı kritik işler için boşta tutar.
Bu taktikler birlikte uygulandığında, throttling duvarına çarpma sıklığınız belirgin biçimde azalır. Kampanya gününde kota dolmaya başladığında, sistem hangi güncellemenin gerçekten anlık gönderilmesi gerektiğini, hangisinin birkaç saniye bekleyebileceğini ayırt edebilir hale gelir. Bunu elle yönetmek mümkün değildir; çok kanallı bir stok ve sipariş yazılımı toplu işlemleri, değişiklik biriktirmeyi ve öncelik sıralamasını birlikte yöneterek kıt kotadan azami verimi çıkarır. Sonuçta amaç her güncellemeyi anında göndermek değil, sınırlı bütçeyi en çok riske maruz ürünlere en doğru anda harcamaktır. Kotayı bir kaynak gibi görüp bilinçli harcadığınızda, anlık olmayan senkron pratikte anlık kadar güvenilir davranır.
Sonuç
Gerçek zamanlı stok senkronu bir pazarlama vaadidir; mühendislik gerçeği değildir. Pazaryeri API'lerinin hız limitleri yüzünden her güncelleme biraz gecikir ve bu gecikme tam da en yoğun, en kritik anda, yani kampanyada en çok hissedilir. Throttling stoğunuzu en hızlı değiştiği anda bayatlatır ve aşırı satıştan kaçan fırsata kadar her hatayı en pahalı anda yaptırır. Doğru strateji bu fiziği inkâr edip gerçek zamanı kovalamak değil, kabul edip köprülemektir: gecikmeyi yutan akıllı bir tampon stok ve kıt kotayı en kritik ürünlere yönelten bir öncelik kuyruğu. Bunları kurduğunuzda «anlık» olmayan senkron, anlıkmış gibi güvenilir davranır. Çünkü gerçek zamanlılık ulaşılacak bir hedef değil, yönetilecek bir boşluktur.
