Çift sipariş konuşulduğunda ilk söylenen cümle hep aynıdır: "Müşteri butona iki kez basmış." Bu açıklama seni rahatlatır çünkü sorumluluğu dışarı atar. Ne var ki stok tablonda eksik iki kod, kasanda tek ödeme ve destek kutunda "iki kere çekilmiş" mesajı varken bu cümlenin hiçbir kıymeti yok. Çift tıklama yalnızca tetikleyicidir; asıl kusur, yazılımın aynı işi iki kez yapmayı reddedememesidir.
Bir dijital ürün satış scripti fiziksel mağazadan farklıdır: teslim ettiğin şey geri alınamaz. Yanlış giden bir kargo dönerken, teslim edilmiş bir kod dönmez. Bu yüzden çift sipariş, e-pin işinde doğrudan zarar hanesine yazılır. Aşağıda çift siparişin beş ayrı doğum yerini tek tek açacağız; bunların hiçbiri "müşteri sabırsız" değil. Her biri için doğrulama yöntemi ve kalıcı çözümü tabloya döktük.
Çift tıklama gerçekten suçlu mu, yoksa sadece tanık mı?
Bir müşteri ödeme butonuna iki kez bastığında tarayıcı iki istek gönderir. Sağlam bir yapıda ikinci istek daha doğmadan ölür: buton kilitlenir, form tek kullanımlık bir işlem anahtarı taşır ve sunucu o anahtarı ikinci kez gördüğünde "bunu zaten işledim" diyerek mevcut siparişi döndürür. Yani çift tıklama olur ama çift sipariş olmaz. Arayüzde buton kilidi koymak iyi bir alışkanlıktır, fakat tek başına bir savunma değildir; ağ yavaşlığında tarayıcı isteği kendi başına tekrarlayabilir.
Bu yüzden savunmanın yeri sunucudur. Sipariş oluşturma isteği idempotent olmalı: aynı anahtarla kaç kez çağrılırsa çağrılsın tek bir sonuç üretmeli. Bunu sağlamanın yolu, sipariş tablosunda o anahtar üzerinde benzersiz bir kısıt tanımlamaktır. İkinci istek veritabanı seviyesinde reddedilir, uygulama da bu reddi hata değil "zaten var" olarak yorumlar. Bu tek tasarım kararı, e-pin satış scripti kullanan işletmelerdeki çift kayıtların büyük kısmını daha kaynağında bitirir.
Ödeme bildiriminin iki kez gelmesi bir arıza değil, tasarımdır
Ödeme sağlayıcıları başarılı işlemi sana arka kanaldan haber verir. Bu haberin bir kez geleceğine dair hiçbir garanti yoktur; tam tersine, sağlayıcı senden onay alamazsa aynı bildirimi tekrar tekrar gönderir. Sunucun 200 yerine 500 döndüyse, zaman aşımına düştüyse ya da yanıtı geciktiyse bildirim yeniden gelir. Yazılım her bildirimde sipariş oluşturuyorsa, bir ödeme için üç kod teslim edebilirsin.
Doğru kurulum şöyle çalışır: bildirim geldiğinde önce sağlayıcının işlem numarası aranır. Bu numara daha önce kaydedilmişse hiçbir şey yapılmaz, sadece başarı yanıtı döner. Kaydedilmemişse tek bir işlem içinde sipariş oluşturulur, stok düşülür ve numara benzersiz alana yazılır. Bu akışta bildirimin yüz kez gelmesi bile zararsızdır. Bir e-pin yazılımı değerlendirirken sormanız gereken en teknik ama en kârlı soru budur: bildirim tekrarını neye göre eliyorsunuz?
| Çift siparişin kaynağı | Belirti | Doğrulama yolu | Kalıcı çözüm |
|---|---|---|---|
| Arka kanal bildirimi tekrarı | Tek ödemede 2-3 sipariş, aynı işlem numarası | Bildirim kayıtlarında aynı numarayı say | İşlem numarasına benzersiz kısıt |
| Kullanıcı çift tıklaması | Saniyeler arayla iki kayıt, iki ayrı ödeme | Kayıt zaman damgalarını karşılaştır | Tek kullanımlık işlem anahtarı |
| Tarayıcı / ağ istek tekrarı | Müşteri tek tıkladığını söylüyor | Sunucu erişim kayıtlarında tekrar isteği ara | Sunucu tarafı idempotency |
| Eşzamanlı stok yarışı | Aynı kod iki müşteriye gitti | Kod teslim kayıtlarını eşleştir | Satır kilidi veya atomik güncelleme |
| Zamanlanmış görev üst üste binmesi | Toplu teslimler mükerrer | Görev çalışma süresi ile aralığı kıyasla | Çalışma kilidi ekle |
Aynı kodun iki müşteriye gitmesi neden ayrı bir felakettir?
Çift siparişin en pahalı türü mükerrer kayıt değil, mükerrer teslimdir. İki müşteri aynı anda son kodu almak istediğinde yazılım "boştaki kodu seç, sonra teslim edildi olarak işaretle" mantığıyla çalışıyorsa iki istek de aynı kodu seçebilir. İkisi de teslim alır, biri kodu kullanır, diğeri kullanamaz ve haklı olarak iade ister. Sen ise hem parayı geri verirsin hem itibarını.
Çözüm iki adımı tek adıma indirmektir: kodu seçmekle işaretlemek aynı atomik işlem içinde olmalı, ya da seçim satır kilidiyle korunmalıdır. Böylece ikinci istek o satırı göremez, bir sonrakini alır; stok bittiyse dürüstçe "stok yok" der. Kampanya saatlerinde eşzamanlı talep on kat artar, bu yüzden yarış koşulları tam da en çok satış yaptığın anda ortaya çıkar. Yüksek trafikte çökmeyen bir epin yazılım, hızından değil kilitleme disiplininden dolayı ayakta kalır.
Çift sipariş vakalarının kaynak dağılımı
- Ödeme bildirimi tekrarı 45%
- İstemci tarafı istek tekrarı 25%
- Eşzamanlı stok yarışı 20%
- Zamanlanmış görev çakışması 10%
Veritabanı kısıtı olmayan bir yapıda hiçbir kontrol yeterli değildir
Geliştiricinin "kontrol ekledim, artık olmaz" dediği çözümlerin çoğu şöyle çalışır: önce bak var mı, yoksa ekle. Bu ikisi arasında milisaniyelik bir boşluk vardır ve iki istek tam o boşlukta buluşursa ikisi de "yok" cevabını alır, ikisi de ekler. Uygulama katmanındaki kontrol bir nezaket kuralıdır; kanunu veritabanı koyar. Benzersiz indeks olmadan yazılan hiçbir tekillik kontrolü eşzamanlılığa dayanmaz.
Pratikte üç alanda benzersizlik ararsın: sağlayıcının işlem numarası, senin ürettiğin sipariş anahtarı ve teslim edilen kodun kendisi. Bu üçü kısıtlandığında sistem çift kaydı fiziksel olarak yapamaz. Üstüne, ödeme ile stok düşümü tek bir veritabanı işlemi içinde yürütülmeli; biri başarısız olursa ikisi de geri alınmalı. Yarısı yazılmış siparişler, sonradan elle temizlenmesi en zor kayıt türüdür ve muhasebe raporlarını da bozar.
Sipariş tablonda sağlayıcı işlem numarası alanına benzersiz indeks koy. Tek bu adım, bildirim tekrarından doğan çift teslimlerin neredeyse tamamını daha veritabanına yazılmadan durdurur.
Mükerrer kayıtları sonradan temizlemek neden en kötü strateji?
Bazı işletmeler sorunu "her sabah mükerrerleri bul ve sil" şeklinde çözmeye çalışır. Bu yaklaşımın üç kusuru var. Birincisi, kod zaten teslim edilmiştir; kaydı silmek zararı geri getirmez. İkincisi, hangi kaydın gerçek hangisinin fazlalık olduğunu her zaman kesin bilemezsin ve yanlış kaydı silmek meşru bir müşteriyi kodsuz bırakır. Üçüncüsü, bu temizlik cirodan düşen tutarları ve stok sayımını geriye dönük bozar.
Doğru strateji önlemektir. Yazılım çift işi kabul etmediğinde temizlik ihtiyacı sıfıra yaklaşır. Buna ek olarak her siparişin hangi bildirimden doğduğunu gösteren bir iz kaydı tutmalısın: hangi istek, ne zaman, hangi numarayla geldi ve ne yapıldı. Bu iz olmadan çift siparişi teşhis etmek karanlıkta iğne aramaktır. İzlenebilirlik, bir dijital ürün satış yazılımı seçerken tasarımdan sonra gelen değil, tasarımdan önce gelen kriterdir.
Pinova çift siparişi hangi noktalarda engelliyor?
Pinova, e-pin satan işletmeler için geliştirilmiş lisanslı bir satış yönetim yazılımıdır; kod satmaz, kod satanın altyapısını kurar. Çift sipariş konusunu tek bir yamayla değil zincirin her halkasında ele alır: sipariş oluşturmada tek kullanımlık anahtar, ödeme bildiriminde işlem numarası tekilliği, stok teslimatında satır kilidi ve zamanlanmış görevlerde çalışma kilidi bulunur.
Bunun üstüne her siparişin bildirim geçmişi panelden görülebilir; bir ödemenin kaç kez haber verildiğini ve sistemin kaçını yok saydığını görürsün. Böylece "acaba oluyor mu" tahmininden çıkıp ölçmeye geçersin. Teknik ayrıntıları özellikler bölümünde, lisans paketlerini fiyat bölümünde inceleyebilirsin.
| Kontrol maddesi | Katman | Olması gereken | Yoksa riski |
|---|---|---|---|
| Sağlayıcı işlem numarası tekilliği | Veritabanı | Benzersiz indeks | Tek ödemede çok teslim |
| Tek kullanımlık sipariş anahtarı | Uygulama + veritabanı | Her formda üretilir ve saklanır | Çift tıklama çift kayıt üretir |
| Kod teslimatında kilit | Veritabanı | Satır kilidi veya atomik güncelleme | Aynı kod iki müşteriye gider |
| Ödeme + stok tek işlemde | Uygulama | Hepsi ya da hiçbiri | Yarım sipariş, bozuk rapor |
| Görev çalışma kilidi | Zamanlanmış görevler | Önceki bitmeden yenisi başlamaz | Toplu mükerrer teslim |
| Bildirim iz kaydı | Kayıt/izleme | Her bildirim ayrı ayrı saklanır | Teşhis imkânsız hâle gelir |
| Buton kilidi ve geri bildirim | Arayüz | Tıklamadan sonra devre dışı | Gereksiz yükün tamamı sunucuya biner |
Çift teslimi silerek değil, engelleyerek bitir
Pinova'da tekillik kısıtları, stok kilidi ve bildirim izi kutudan çıkar gelir. Mükerrer temizliği yapan bir görev yazmana gerek kalmaz.
Butona iki kez basmayı arayüzde engellesem yeterli olur mu?
Olmaz. Ağ tekrarları ve ödeme sağlayıcısının tekrarlı bildirimleri arayüzden bağımsızdır. Asıl savunma sunucu ve veritabanı katmanında kurulmalıdır.
Ödeme sağlayıcısı neden aynı bildirimi tekrar gönderiyor?
Çünkü senden geçerli bir onay yanıtı alamadığında işlemin kaydedilmediğini varsayar. Bu bir arıza değil, kasıtlı güvenilirlik tasarımıdır; senin tarafın tekrarı elemekle yükümlüdür.
Aynı kod iki müşteriye gittiyse ne yapmalıyım?
Kısa vadede ikinci müşteriye yeni kod ver ve durumu şeffaf açıkla. Kalıcı çözüm, kod seçimi ile teslim işaretlemesini tek atomik işlemde birleştirmektir.
Mevcut sisteme benzersiz kısıt eklemek riskli mi?
Tabloda hâlihazırda mükerrer kayıt varsa kısıt eklenmez; önce mevcut veriyi temizlemen gerekir. Bu yüzden işlem canlı trafiğin en düşük olduğu saatte ve yedek alınarak yapılmalıdır.
Çift sipariş, yazılımın "aynı işi iki kez yapmayı reddetme" yeteneğinin sınavıdır ve bu sınav müşteri kalabalıklaştığında verilir. Tekillik kısıtlarının, stok kilidinin ve bildirim izinin bir arada nasıl çalıştığını kendi elinle sınamak istersen canlı demo üzerinde bir siparişi bilerek üst üste göndermeyi dene; sistemin ikinci isteği nasıl sessizce yok saydığını göreceksin.