E-pin satan çoğu işletme, kod havuzunu basit bir liste sanır: kodları yükle, satış olunca en üsttekini gönder. Kâğıt üzerinde kusursuz görünür. Sonra bir gün iki müşteri aynı anda son adede tıklar, ödeme sağlayıcısı iki bildirimi milisaniye farkla gönderir ve aynı kod iki kişiye teslim edilir. O andan sonra elinde iade talebi, itibar kaybı ve nedenini kimsenin açıklayamadığı bir kayıt kalır.
Bu olay şans eseri yaşanmaz; kod havuzu mimarisi yanlış kurulduğunda matematiksel olarak kaçınılmazdır. Bu yazıda bir e-pin satış scriptinin kod havuzunu nasıl kurgulaması gerektiğini, kilit stratejilerini, rezervasyon mantığını ve şifreleme tarafını mühendislik diliyle ama işletme sahibinin anlayacağı netlikte anlatacağım.
Kod havuzu neden basit bir tablo değildir?
Havuzdaki her kod bir varlıktır ve para değeri taşır. Bu yüzden kodun sadece "satıldı mı" bilgisi yetmez. Sağlam bir epin yazılım mimarisinde her kodun en az dört durumu bulunur: boşta, rezerve, teslim ve iptal. Boştaki kod satışa hazırdır. Rezerve kod bir siparişe bağlanmış ama ödemesi henüz onaylanmamıştır. Teslim kod müşteriye gitmiştir. İptal kod ise iade, tedarikçi hatası veya süre dolumu nedeniyle havuzdan çıkarılmıştır.
Bu dört durumun arasındaki geçişler tek yönlüdür ve geri dönüşleri kayıt altına alınmalıdır. Rezerve bir kod ödemesi iptal olduğunda boşta durumuna dönebilir, ancak bu dönüş sessizce yapılmaz; kimin hangi siparişten serbest bıraktığı günlüğe yazılır. Bu iz olmadan bir uyuşmazlıkta hangi kodun nereye gittiğini kanıtlayamazsın.
Çift teslimat tam olarak nasıl oluşuyor?
Klasik hata şudur: sistem önce "boştaki ilk kodu seç" sorgusunu çalıştırır, sonra ayrı bir işlemle o kodu satıldı diye işaretler. İki istek aynı anda geldiğinde ikisi de aynı kodu seçer, sonra ikisi de aynı kodu işaretler. Arada geçen milisaniyeler, iki müşterinin aynı ürünü almasına yeter. Sorun kodda değil, seçme ile işaretleme arasındaki boşluktadır.
Doğru çözüm, seçme ve kilitleme işlemini tek bir atomik adımda yapmaktır. Veritabanı seviyesinde satır kilidi alınır, kod rezerve edilir ve ancak ondan sonra ödeme akışı devam eder. Aşağıdaki tablo yaygın yaklaşımları ve gerçek davranışlarını karşılaştırıyor.
| Yaklaşım | Çalışma mantığı | Çakışma riski | Ölçeklenme |
|---|---|---|---|
| Seç sonra işaretle | İki ayrı sorgu, kilit yok | Çok yüksek | Kötü |
| Uygulama içi kilit | Tek sunucuda bellek kilidi | Orta | Tek sunucuda sınırlı |
| Satır kilidi ile seçim | Kilitli seçim, atomik güncelleme | Çok düşük | İyi |
| Rezervasyon kuyruğu | Kod önce rezerve, sonra teslim | Çok düşük | Çok iyi |
| Benzersiz kısıt | Kod-sipariş eşleşmesi tekil | Düşük (son savunma) | İyi |
Rezervasyon süresi ne kadar olmalı?
Rezervasyon, kodu siparişe bağlayıp ödeme sonucunu beklemektir. Süre çok kısa olursa yavaş ödeme yöntemlerinde kod serbest kalır ve müşteri ödemeyi yaptığı halde kod başkasına gider. Çok uzun olursa stoğun bir kısmı gereksiz yere bloke olur, vitrin "tükendi" gösterir ve satış kaçırırsın.
Pratikte doğru yaklaşım, rezervasyon süresini ödeme yöntemine göre değiştirmektir. Kart ödemesi saniyeler içinde sonuçlanır, 10 dakika fazlasıyla yeter. Havale ve EFT'de süre saatlerle ölçülür, bu durumda kod rezerve edilmez; sipariş ödeme onayına kadar kodsuz bekletilir. İyi tasarlanmış bir dijital ürün satış scripti bu ayrımı yöntem bazında yapılandırılabilir hale getirir.
Kod havuzu kaynaklı destek taleplerinin dağılımı
- Kullanılmış/geçersiz kod şikâyeti 45%
- Rezervasyon süresi dolan siparişler 25%
- Stok bittiği halde satışa açık ürün 20%
- Çift teslimat ve iade 10%
Kodlar veritabanında açık metin olarak durmalı mı?
Kesinlikle hayır. Kod havuzu, sitendeki en değerli tablodur; bir veri sızıntısında saldırganın ilk hedefi budur. Teslim edilmemiş kodlar uygulama seviyesinde şifrelenmeli, şifreleme anahtarı web kök dizininin dışında tutulmalı ve veritabanı yedekleri anahtarla birlikte aynı yere kopyalanmamalıdır. Böylece yedek dosyası ele geçse bile kodlar okunamaz.
İkinci katman, panel tarafında görünürlüğün kısıtlanmasıdır. Kod listesi ekranında tam kod değil maskelenmiş hali gösterilir; tam kodu görüntüleme işlemi ayrı yetki ister ve her görüntüleme günlüğe yazılır. Bu, hem dış saldırıya hem de içeriden sızıntıya karşı çalışan bir önlemdir. Ciddi bir e-pin satış yazılımı bu iki katmanı varsayılan olarak getirir, sonradan eklenen bir özellik gibi sunmaz.
Sipariş satırı ile kod arasındaki eşleşmeye benzersiz kısıt tanımla. Uygulama katmanındaki her mantık hatası bile olsa, aynı kod ikinci bir siparişe yazılamaz.
Toplu kod yüklemesinde nelere dikkat etmelisin?
Tedarikçiden gelen dosyaların içinde tekrar eden satırlar, görünmeyen boşluk karakterleri, yanlış ürüne ait kodlar ve daha önce yüklenmiş partiler sık görülür. Yükleme ekranı bunları sessizce kabul ederse havuz baştan kirlenir ve sorun ancak müşteri şikâyetiyle ortaya çıkar. Yükleme akışı bu yüzden bir içe aktarma değil, bir doğrulama adımı olarak tasarlanmalıdır.
Doğru akış şöyle işler: dosya alınır, satırlar normalize edilir, havuzun tamamına karşı tekillik kontrolü yapılır, format kalıbı doğrulanır ve ancak temiz satırlar havuza yazılır. Reddedilen satırlar gerekçesiyle birlikte ekrana dökülür. Ayrıca her yükleme bir parti numarası alır; böylece tedarikçiden sorunlu bir parti geldiğinde o partinin tamamını tek hamlede karantinaya alabilirsin.
Havuz sağlığını hangi kontrollerle izlemelisin?
Kod havuzu kurulup unutulacak bir yapı değildir; sürekli izlenmesi gereken bir envanterdir. Aşağıdaki kontrol listesi, havuzun günlük ve haftalık sağlık taramasını oluşturur. Bu kontrollerin panelde otomatik uyarıya bağlanması, sorunları müşteri fark etmeden yakalamanı sağlar.
| Kontrol | Eşik | Sıklık | Tetiklenecek aksiyon |
|---|---|---|---|
| Kritik stok uyarısı | Günlük satışın 2 katı altı | Saatlik | Tedarikçiye sipariş |
| Takılı rezervasyon | Süre aşımı + 15 dk | 5 dakikada bir | Kodu boşta durumuna al |
| Tekrarlı kod taraması | Sıfır tolerans | Her yüklemede | Satırı reddet |
| Geçersiz kod şikâyeti | Parti başına %1 | Günlük | Partiyi karantinaya al |
| Uzun süre satılmayan kod | 90 gün | Haftalık | Son kullanma kontrolü |
| Yetkili kod görüntüleme | Olağandışı yoğunluk | Günlük | Güvenlik incelemesi |
Havuzunu kaza değil mimari korusun
Pinova; atomik kod kilitleme, yöntem bazlı rezervasyon, şifreli havuz ve parti bazlı karantina yapısını hazır sunar. Lisans paketlerini incele, kendi hacmine uygun olanı seç.
Aynı kodun iki müşteriye gitmesi nasıl kesin olarak engellenir?
Seçme ve kilitleme işlemini tek atomik adımda yapman, kodu ödeme öncesinde rezerve etmen ve sipariş-kod eşleşmesine veritabanı seviyesinde benzersiz kısıt koyman gerekir. Bu üç katman birlikte uygulandığında çakışma pratikte imkânsız hale gelir.
Rezervasyon süresi ne kadar olmalı?
Kart ödemelerinde 10 dakika yeterlidir. Havale ve EFT gibi yavaş yöntemlerde kod rezerve edilmemeli, sipariş ödeme onayına kadar kodsuz bekletilmelidir. Süre ödeme yöntemine göre ayarlanabilir olmalıdır.
Kodları veritabanında şifrelemek performansı düşürür mü?
Hayır. Şifreleme yalnızca teslim anında tek bir kayıt için çözülür, liste ekranlarında maskelenmiş değer gösterilir. Bu yüzden yük ihmal edilebilir düzeydedir ve sağladığı güvenlik kazancı çok daha büyüktür.
Tedarikçiden gelen bozuk partiyi nasıl yönetirim?
Her yüklemeye parti numarası verirsen, şikâyet oranı eşiği aşan partiyi tek hamlede karantinaya alabilir, o partiden teslim edilmiş kodları listeleyip proaktif değişim yapabilirsin. Parti numarası olmadan bu iş tek tek elle yürütülür.
Kod havuzu, e-pin işinin kasasıdır; mimarisi doğru kurulduğunda hiç konuşulmaz, yanlış kurulduğunda her gün konuşulur. Kilitleme, rezervasyon, parti yönetimi ve şifreli havuzun gerçek bir panelde nasıl işlediğini görmek için canlı demo üzerinden bir test siparişi oluşturabilir, ardından fiyatlandırma sayfasından kendi hacmine uygun lisansı seçebilirsin.