Çoğu satıcı bakiye konusunu bir muhasebe süsü sanır. "Müşterinin cüzdanında 250 lira yazıyor, siparişi verince 50 lira düşüyor, bitti" diye düşünür. Oysa bir e-pin scripti için bakiye, sitenin en sıcak ve en çok yarışılan tek satırıdır. Aynı kullanıcı aynı saniyede iki sekmeden iki siparişi tetiklediğinde, o tek satır bir anda iki farklı sürecin kavgasına dönüşür. Kavganın sonucu senin kasandan çıkar.
Ve bu, "çok satış olunca olur" diye ertelenecek bir konu değil. Kampanya günü, canlı yayın anonsu, ya da sadece bağlantısı kopan bir müşterinin butona üç kez basması yeter. Bu yazıda dijital ürün satış yazılımı tarafında atomik bakiye güncellemesinin ne olduğunu, olmadığında paranın hangi delikten aktığını ve kendi panelinde bunu 20 dakikada nasıl sınayacağını anlatıyorum. Teknik, ama kod bilmeden de takip edebileceğin bir dille.
Atomik güncelleme nedir, neden "sonra bakarız" denecek bir detay değil?
Atomik işlem, bölünemeyen işlem demektir: ya tamamı olur ya hiçbiri. Bakiye tarafında bunun karşılığı şudur; bakiyeyi okuma, yeterli mi diye kontrol etme, düşme ve hareket satırını yazma adımlarının hepsi tek bir bütün gibi davranmalı. Arada başka bir sipariş araya giremesin. Bir e-pin satış scripti bu adımları ayrı ayrı, gevşek biçimde yapıyorsa açık orada doğar.
Pratikte iki şey gerekir. Birincisi, bakiye düşümünün koşulu veritabanının kendisine söylenmeli: "bakiye 50'den büyük veya eşitse 50 düş" cümlesi tek hamlede çalışmalı. İkincisi, bu düşüm ile stok rezervasyonu ve sipariş kaydı aynı işlem (transaction) içinde yer almalı. Pinova gibi bu mantığı çekirdeğe koyan bir e-pin yazılımı kullanıyorsan, satıcı tarafında ayar yapmana gerek kalmaz; yapmadığın hâlde çalışır. Kurulu olmadığında ise kimse sana hata mesajı göstermez. Sadece ay sonunda tablolar tutmaz.
Aynı saniyede iki sipariş geldiğinde scriptin içinde gerçekte ne oluyor?
Senaryoyu yavaşlatarak izle. Müşterinin bakiyesi 100 lira. İki sekmede de 80 liralık bir ürün var. Birinci süreç bakiyeyi okur: 100. "Yeterli" der. İkinci süreç, birincisi henüz yazmadan bakiyeyi okur: yine 100. O da "yeterli" der. Birinci süreç 100 - 80 = 20 yazar. İkinci süreç de elindeki eski fotoğrafla 100 - 80 = 20 yazar. Sonuç: müşteri 160 liralık ürün aldı, bakiyesinden 80 lira düştü.
Bu hataya yarış durumu (race condition) denir ve tesadüfe bağlı olduğu için test ortamında neredeyse hiç görünmez. Elle deneyince hep doğru çalışır, çünkü senin tıklamaların arasında yüz milisaniye var. Gerçek trafikte ise iki istek arasındaki fark birkaç milisaniyeye iner. Üstelik en çok ürün verdiğin, yani en çok kaybedeceğin anda iner: kampanya, indirim saati, yeni oyun çıkışı.
Önce oku sonra yaz yapan panel neden matematiksel olarak açık verir?
Çünkü okuduğun değer, yazdığın anda artık geçerli olmayabilir. "Önce oku, uygulamada hesapla, sonra yaz" kalıbı bakiyeyi mutlak bir sayıyla ezer. O sayı, okuma anındaki dünyanın fotoğrafıdır. Arada dünya değiştiyse, yazdığın şey bir düzeltme değil, bir geri sarma olur. Doğru kalıp ise bakiyeyi ezmek değil, göreli değiştirmektir: "mevcut bakiyeden şu kadar çıkar, ama ancak yetiyorsa".
Buradaki fark bir zevk meselesi değil, muhasebe meselesidir. Mutlak yazma, aradaki tüm işlemleri görünmez biçimde siler. Göreli ve koşullu yazma ise yetmediğinde hiç çalışmaz; sana "0 satır etkilendi" der. O yanıt senin güvenlik kapındır: satır etkilenmediyse siparişi reddedersin, stoğu geri bırakırsın, müşteriye net bir mesaj gösterirsin. İyi bir dijital ürün satış scripti bu "0 satır" durumunu bir hata değil, normal bir iş akışı olarak ele alır.
| Yaklaşım | Çift harcama riski | Yoğunlukta davranış | Denetlenebilirlik |
|---|---|---|---|
| Oku → uygulamada hesapla → mutlak yaz | Yüksek | Sessiz veri kaybı | Zayıf |
| Göreli yaz (koşulsuz çıkarma) | Orta | Eksi bakiye oluşabilir | Orta |
| Koşullu tek hamle güncelleme | Düşük | Yetmezse reddeder | İyi |
| Koşullu güncelleme + hareket satırı + işlem bütünlüğü | Yok denecek kadar az | Tutarlı, izlenebilir | Tam |
Kilit mi kullanmalı, tek satırlık koşullu güncelleme mi?
İki yol da işe yarar, maliyetleri farklıdır. Satır kilidi (işlem içinde kaydı okurken kilitleme) en sezgisel yoldur: kaydı tut, hesapla, yaz, bırak. Anlaşılırdır ve karmaşık hesaplar için elverişlidir. Bedeli, kilit süresi boyunca diğer isteklerin beklemesidir; kilidi uzun tutarsan yoğun saatlerde kuyruk oluşur. Kural basittir: kilidin içinde asla dış servise istek atma, e-posta gönderme, API bekleme.
Koşullu tek hamle güncelleme ise daha yalındır ve çok daha hızlıdır. Tek cümlede hem kontrolü hem düşümü yaparsın, sonra etkilenen satır sayısına bakarsın. Çoğu e-pin satış yazılımı senaryosu için doğru tercih budur. Karma yaklaşım da meşrudur: bakiye düşümünü koşullu güncellemeyle yap, stok tahsisini ayrı bir kayıtta rezervasyon mantığıyla yürüt, ikisini tek işlemde bağla. Önemli olan seçtiğin yolu her yerde aynı biçimde uygulamak; bir yerde kilit, başka yerde mutlak yazma karışımı en kötü sonucu verir.
Bakiye kaynaklı şikâyetlerin gerçek dağılımı
- Eşzamanlı istek / çift harcama 45%
- Yarım kalan iade ve geri yükleme 25%
- Kupon ve bonusun iki kez sayılması 20%
- Diğer (elle düzeltme, yanlış kayıt) 10%
İade, kupon ve stok düşümü aynı işlemde değilse ne kaybediyorsun?
Bakiyeyi doğru düşürdün, ama e-pin kodu tükendiği için sipariş başarısız oldu. Şimdi parayı geri yüklemen gerekiyor. Bu geri yükleme ayrı bir adımda, ayrı bir istekte yapılıyorsa yeni bir açık doğar: geri yükleme iki kez çalışırsa müşteriye bedava bakiye vermiş olursun. Bu yüzden her geri yüklemenin bir benzersiz referansı olmalı ve aynı referansla ikinci kez çalıştığında hiçbir şey yapmamalı. Buna fikir olarak "aynı isteği tekrar çalıştırınca sonuç değişmez" güvencesi denir.
Kupon tarafı da aynı mantıkla yürür. Kuponun kullanım sayacı, siparişin oluşturulduğu işlemin içinde artmalı. Ayrı artırırsan, sipariş iptal edildiğinde sayaç şişmiş kalır ya da tam tersi, tek kullanımlık kupon beş kez harcanır. Stok için de öyle: kodu "satıldı" olarak işaretleme ile bakiyeyi düşme aynı bütünün parçasıdır. Bir epin yazılım mimarisinde bu üç kalemi tek işlem sınırında toplamak, sonradan yazılacak yüzlerce satır düzeltme kodundan ucuzdur.
Kullanıcı tablosundaki bakiye alanını bir önbellek gibi düşün; asıl gerçek, hareket satırlarının toplamıdır. Gece çalışan bir kontrol işi bu iki sayıyı karşılaştırıp fark bulduğunda seni uyarmalı. Fark her zaman bir hikâye anlatır.
Bunu kendi panelinde 20 dakikada nasıl test edersin?
Kod okumadan da sınayabilirsin. Test hesabına yuvarlak bir bakiye yükle, mesela 100 lira. 80 liralık bir ürünü iki farklı sekmede sepete al, iki sekmeyi yan yana koy ve ödeme butonlarına mümkün olduğunca aynı anda bas. Doğru kurulmuş bir sistem tek siparişi geçirir, ikinciye "yetersiz bakiye" der. Yanlış kurulmuş olan iki siparişi de kabul eder ve bakiyeyi 20'de bırakır. Bu deneyi üç kez tekrarla; bir kez bile ikisi geçtiyse açığın var.
İkinci test daha sert: aynı hesapla 30 saniye içinde on küçük sipariş ver, sonra hareket dökümündeki satırların toplamını bakiyeyle karşılaştır. Üçüncü test iade testidir; stoğu bilerek boşalt, sipariş oluştur, başarısız olmasını sağla ve bakiyenin tam olarak eski değerine döndüğünü kontrol et. Bu üç deney, bir e-pin satış scripti hakkında onlarca sayfa özellik listesinden daha çok şey söyler. Satın alma kararı öncesi demo panelde de aynı üçünü uygulaman en ucuz sigortadır.
| Kontrol maddesi | Nasıl doğrularsın | Geçme ölçütü |
|---|---|---|
| Eşzamanlı iki sipariş | İki sekmede aynı anda ödeme | Yalnızca biri geçer |
| Koşullu düşüm | Bakiyeden fazla tutarlı sipariş | Eksi bakiye asla oluşmaz |
| Başarısız siparişte geri yükleme | Stoğu boşalt, sipariş dene | Bakiye birebir eski değer |
| Tekrarlı geri yükleme koruması | Aynı iadeyi iki kez tetikle | İkincisi hiçbir şey yapmaz |
| Tek kullanımlık kupon | Aynı kuponla hızlı iki sipariş | Tek kullanım kaydı |
| Döküm–bakiye mutabakatı | Hareket toplamı vs bakiye alanı | Fark sıfır |
Bakiye tarafı baştan doğru kurulmuş bir altyapı istiyorsan
Pinova'nın cüzdan çekirdeği koşullu güncelleme, işlem bütünlüğü ve hareket dökümü üçlüsünü hazır getirir. Sen kampanyayı düşünürsün, matematiği yazılım üstlenir.
Atomik bakiye güncellemesi küçük siteler için de gerekli mi?
Evet, çünkü risk ciro ile değil eşzamanlılıkla ilgilidir. Günde 20 sipariş alan bir sitede bile tek bir müşterinin butona üç kez basması ya da bağlantısının kopup yeniden denemesi aynı açığı tetikler.
Bakiyeyi eksiye düşmemesi için kodda kontrol koymak yetmez mi?
Yetmez. Uygulama tarafındaki kontrol, okuma anındaki değeri kontrol eder. Kararın veritabanına, güncelleme cümlesinin koşulu olarak taşınması gerekir; yoksa iki istek de kontrolü geçer.
Hareket dökümü tutmak performansı düşürür mü?
Pratikte hayır. Her işlemde tek bir ek satır yazılır ve bu satır indeksli bir tabloya gider. Buna karşılık kazandığın şey, şikâyetleri dakikalar içinde kapatabilmek ve mutabakat yapabilmektir.
Mevcut panelimde bu açık varsa sıfırdan mı kurmalıyım?
Şart değil. Önce ödeme ve cüzdan akışını tek noktaya toplamak, sonra düşüm ile hareket kaydını aynı işlem içine almak çoğu durumda yeterlidir. Bakiye mantığı dağınık biçimde onlarca dosyaya yayıldıysa, çekirdeği sağlam bir altyapıya geçmek daha hesaplı olur.
Özetle: bakiye, sitenin en kalabalık kavşağıdır ve orada trafik ışığı yoksa kaza kaçınılmazdır. Hangi altyapıyı kullanıyorsan kullan, yukarıdaki üç testi bugün uygula; sonuçlar seni şaşırtabilir. Pinova'nın cüzdan, stok ve sipariş akışını aynı işlem sınırında nasıl tuttuğunu kendi gözünle görmek istersen canlı demo üzerinden aynı senaryoları dene, özellikler listesini ve fiyat seçeneklerini karşılaştırdıktan sonra kararını ver.