Çoğu işletme sahibi stok senkronunun bir ayar meselesi olduğunu sanır. Panelde bir kutucuk var, tedarikçinin verdiği bir adres var, ikisini birleştirdin mi iş bitti diye düşünülür. Oysa senkron bozulduğunda ortaya çıkan tabloya bak: sistem 40 adet gösterirken elde 6 kod kalmıştır, aynı pini iki müşteri almıştır, iptal edilen bir sipariş stoğa geri dönmemiştir. Bunların hiçbiri kutucukla ilgili değildir; hepsi senkronun hangi anda, hangi sırayla ve hangi otoriteye göre yapıldığıyla ilgilidir.
İşin en can sıkıcı tarafı, arıza sessiz gelir. Stok senkronu bozulduğunda ekranda kırmızı bir uyarı çıkmaz; satış devam eder, kasa dolar, sorun ancak müşteri "kod çalışmıyor" yazdığında görünür. O noktada artık teknik bir hata değil, itibar zararını konuşuyorsundur. Bu yazıda dijital ürün satış yazılımı tarafında senkronun tam olarak nerede kırıldığını, hangi kararların bunu kaçınılmaz hale getirdiğini ve düzgün kurulmuş bir e-pin satış scriptinin bu riski nasıl sıfıra yakın tuttuğunu tek tek açıyoruz.
Senkron gerçekten "bozulmuyor" — hiç kurulmamış olabilir mi?
Sahada gördüğümüz vakaların büyük kısmında senkron diye anlatılan şey aslında tek yönlü bir kopyalamadır. Tedarikçiden gelen liste belli aralıklarla okunur, panelin stok alanına yazılır, bitti. Bu bir senkron değil; fotoğraf çekmektir. Fotoğraf çekildiği anda doğrudur, sonraki saniyede yanlıştır. Senkron, iki tarafın da birbirini etkilediği, çakışmaların bir kurala göre çözüldüğü bir süreçtir.
Doğru kurguda her ürün için tek bir otorite tanımlanır: stok bilgisinin son sözünü kim söyleyecek? Eğer kodlar tedarikçinin havuzundaysa otorite tedarikçidir ve senin panelindeki sayı sadece bir tahmindir; bu yüzden satış anında mutlaka anlık doğrulama yapılmalıdır. Eğer kodları kendi veri tabanına çekip sakladıysan otorite sensin ve tedarikçiden gelen sayı yalnızca bilgilendirmedir. İki tarafı birden otorite kabul eden bir e-pin yazılımı kurgusu, matematiksel olarak çakışmak zorundadır. Karar vermekten kaçınmak, sistemin kararsız kalması demektir.
Aynı pin iki kişiye nasıl satılıyor: kilitlenmenin olmadığı yerde
Çift satışın nedeni neredeyse her zaman aynıdır: stok okuma ile stok düşme arasında geçen o kısa boşluk. İki müşteri aynı saniyede ödemeyi tamamlarsa, sistem ikisine de "stok var" cevabını verir ve aynı kaydı iki kez teslim eder. Kampanya saatlerinde, yayıncı duyurusundan sonraki ilk dakikalarda bu pencere kaçınılmaz biçimde dolar.
Çözüm satır bazlı kilit ve durum makinesidir. Bir kod satılmak üzere seçildiği anda "rezerve" durumuna geçer, o duruma geçiş tek bir işlemde ve koşullu olarak yapılır. İkinci istek aynı kaydı bulamaz, sıradaki koda gider veya "stok tükendi" cevabı alır. Dijital ürün satış scripti tarafında bunun için gereken şey büyük bir sunucu değil, doğru yazılmış birkaç satırdır. Rezervasyonun bir ömrü de olmalıdır: ödeme 15 dakika içinde tamamlanmazsa kod otomatik olarak havuza döner. Aksi halde satılmayan ama satılmış görünen bir "hayalet stok" birikir ve bir süre sonra elinde kod olduğu halde siteye "tükendi" yazdırırsın.
Tedarikçi API'si sana yalan söylediğinde ne yapıyorsun?
Entegrasyonların en kırılgan noktası, karşı tarafın hatalı cevap verdiği anlardır. Zaman aşımı yaşanır, 500 hatası döner, bağlantı kesilir. Kritik soru şudur: istek karşı tarafa ulaştı mı, ulaşmadı mı? Bunu bilemediğin durumda yapılan en yaygın hata, isteği yeniden göndermektir. Sonuç: aynı sipariş için iki kod düşülür, birine para alınır, diğeri kaybolur.
Bu yüzden her sipariş için tekil bir işlem anahtarı üretilmeli ve tedarikçiye o anahtarla gidilmelidir. Karşı taraf aynı anahtarı ikinci kez gördüğünde yeni bir düşüm yapmaz, ilk sonucu tekrar döner. Buna idempotans denir ve ciddi bir e-pin satış yazılımının olmazsa olmazıdır. Desteklemeyen tedarikçilerde ise kendi tarafında "belirsiz" adında bir durum tutup, o siparişleri otomatik tekrar denemeye sokmak yerine mutabakat kuyruğuna atmak gerekir. Emin olmadığın işlemi tekrarlamak yerine işaretlemek, hem parayı hem stoğu korur.
| Arıza belirtisi | Görünen sebep | Gerçek sebep | Kalıcı çözüm |
|---|---|---|---|
| Stok var yazıyor, kod yok | Tedarikçi eksik gönderdi | Otorite tanımı yok, sayı tahmini | Satış anında anlık doğrulama |
| Aynı kod iki müşteride | Yoğunluk / trafik | Rezervasyon kilidi yok | Koşullu durum güncellemesi |
| Stok azalıyor, satış yok | Sistem hata veriyor | Süresi bitmeyen rezervasyonlar | Zaman aşımlı otomatik iade |
| İptalde stok dönmüyor | Kullanıcı hatası | Geri alma akışı yazılmamış | Ters kayıt + durum geçmişi |
| Fark gece büyüyor | Sunucu uykuya geçiyor | Zamanlanmış görev üst üste biniyor | Tek çalışma kilidi (lock) |
| Sayılar her sayfada farklı | Tarayıcı önbelleği | İki ayrı stok kaynağı okunuyor | Tek sorgu kaynağı + görünüm |
Mutabakat olmadan senkron diye bir şey var mı?
Senkronun son halkası mutabakattır: belirli aralıklarla senin kaydınla karşı tarafın kaydını yan yana koyup farkı raporlamak. Bunu yapmayan sistemlerde hata birikir; üç ayda bir envanter sayımı yapıp "nasıl bu kadar açık çıktı" diye şaşırırsın. Günde bir kez çalışan basit bir karşılaştırma görevi, farkı tek kalemde yakalar.
Mutabakatın raporu otomatik düzeltme yapmamalı, fark listesi üretmeli. Çünkü otomatik düzeltme, hatalı bir kaynağı doğru kabul ederek doğru veriyi bozabilir. Fark listesi ise insana karar bırakır: bu 12 kod gerçekten eksik mi, yoksa henüz teslim edilmemiş bir siparişin rezervasyonunda mı? Bu ayrımı yapabilen bir panel, seni yılda onlarca saat ve ciddi bir tutar kurtarır.
Senkron arızalarının kaynak dağılımı
- Rezervasyon/kilit eksikliği 45%
- Tekrarlanan istek (idempotans yok) 25%
- Zamanlanmış görev çakışması 20%
- Manuel müdahale hataları 10%
Panelde hangi kaydı göremiyorsan orada bir açık var
Stok hareketinin izlenebilir olmadığı hiçbir sistemde senkron güvenilir olamaz. Her kodun başına ne geldiğini görebilmelisin: ne zaman havuza girdi, hangi siparişe rezerve edildi, kim teslim etti, iade oldu mu. Bu kayıt zinciri yoksa arıza anında yapabileceğin tek şey tahmin etmektir.
Bunun ikinci faydası daha az konuşulur: personel kaynaklı sızıntıları görünür kılar. Elle stok eklenen, elle kod silinebilen bir panelde açığın kaynağını bulamazsın. Kim, ne zaman, hangi IP ile hangi kaydı değiştirdi sorusunun cevabı varsa tartışma biter. Pinova'nın stok tarafında ısrarla savunduğu yaklaşım budur: silme yok, durum değişikliği ve geçmiş var. Kayıt hiç kaybolmaz, sadece durumu değişir.
Yoğun saat gelmeden iki tarayıcı aç, aynı üründe aynı anda ödeme adımına git. Sistem ikisine de aynı kodu veriyorsa kampanyaya rezervasyon kilidi olmadan giriyorsun demektir. Bu test, yaşanacak onlarca iadeyi önler.
Yeni bir script almak sorunu çözer mi, yoksa taşır mı?
Sık düşülen tuzak şudur: senkron sorunu yaşayan işletme, yazılımı değiştirir ve aynı sorunu yeni panelde yaşar. Çünkü taşınan şey sadece arayüzdür; tedarikçi akışı, ürün eşleştirmesi ve teslim kuralları aynen kopyalanmıştır. Yazılım değiştirmek ancak yeni sistem stok modelini farklı kuruyorsa işe yarar.
Karar verirken sorulacak sorular nettir: ürün bazında otorite tanımlanabiliyor mu, rezervasyonun süresi ayarlanabiliyor mu, tekrarlanan istekler tekil anahtarla korunuyor mu, mutabakat raporu var mı, her hareketin geçmişi tutuluyor mu? Bu beş soruya evet diyen bir dijital ürün satış yazılımı, adı ne olursa olsun işini yapar. Beşine de hayır diyen bir sistem ne kadar şık görünürse görünsün seni aynı yere getirir. Özellikler bölümünde bu maddelerin nasıl karşılandığını satır satır görebilirsin.
| Kontrol maddesi | Ne zaman bakılır | Beklenen durum | Risk |
|---|---|---|---|
| Ürün bazlı stok otoritesi tanımlı mı | Kurulumda | Her üründe tek kaynak | Yüksek |
| Rezervasyon zaman aşımı aktif mi | Haftalık | 10-20 dakika | Yüksek |
| Tekil işlem anahtarı gönderiliyor mu | Entegrasyonda | Her siparişte tekil | Kritik |
| Mutabakat raporu çalışıyor mu | Günlük | Fark listesi üretiyor | Orta |
| Stok hareket geçmişi tutuluyor mu | Sürekli | Silme yok, durum var | Yüksek |
| Zamanlanmış görev kilidi var mı | Aylık | Üst üste binme yok | Orta |
| İptal/iade stoğa dönüyor mu | Haftalık | Ters kayıt oluşuyor | Orta |
Stok açığını tahminle değil kayıtla kapat
Rezervasyon kilidi, tekil işlem anahtarı ve günlük mutabakat raporu kutudan çıkan bir sistemle çalışmak, aynı arızayı her kampanyada yeniden yaşamaktan çok daha ucuzdur. Paket karşılaştırmasına da göz atabilirsin.
Stok senkronunu kaç dakikada bir çalıştırmalıyım?
Sıklık tek başına çözüm değildir. Dakikada bir çalışan yanlış kurgu, saatte bir çalışan doğru kurgudan daha fazla hata üretir. Sağlıklı yaklaşım şudur: bilgilendirme amaçlı senkron 5-15 dakika aralıkla, satış anındaki doğrulama ise her siparişte anlık yapılır.
Kodları kendi veri tabanımda mı tutmalıyım, tedarikçide mi bırakmalıyım?
İkisi de çalışır, karışık olan çalışmaz. Kendinde tutarsan teslim hızı ve bağımsızlık kazanırsın ama güvenlik ve şifreleme sorumluluğu sende olur. Tedarikçide bırakırsan sorumluluk azalır, karşılığında her satışta onun ayakta olmasına bağımlı kalırsın.
Hayalet stok birikmesini nasıl fark ederim?
Rezerve durumda olup belirli süredir hareket görmemiş kayıtları listeleyen basit bir rapor yeterlidir. Bu sayı sürekli artıyorsa rezervasyonların zaman aşımı çalışmıyor demektir; ayarı açmak çoğu durumda sorunu aynı gün bitirir.
Aynı anda birden fazla tedarikçiden aynı ürünü satabilir miyim?
Evet, ancak her tedarikçi için ayrı bir stok havuzu ve öncelik sırası tanımlamalısın. Tek bir sayının arkasında iki kaynak varsa hangisinin düştüğünü bilemezsin. Havuzları ayrı tutup toplamı görüntüde birleştirmek doğru yöntemdir.
Stok senkronu, doğru kurulduğunda hiç konuşulmayan bir konudur; yanlış kurulduğunda ise her kampanyada gündemin birinci maddesi olur. Aradaki fark sunucu gücü ya da tedarikçi seçimi değil, rezervasyon, tekillik ve mutabakat üçlüsünün sistemin çekirdeğinde olup olmamasıdır. Bu üçlünün gerçek bir panelde nasıl göründüğünü merak ediyorsan canlı demo üzerinden stok hareketlerini, rezervasyon sürelerini ve fark raporunu kendi elinle deneyebilir, ardından kurulum adımına geçebilirsin.