Çoğu kişi e-pin satışında en kritik teknik parçanın ödeme entegrasyonu olduğunu sanır. Ödeme sağlayıcısı bağlandı, test siparişi geçti, panel "başarılı" yazdı; iş bitti gibi görünür. Oysa e-pin işinde asıl kırılma noktası ödemenin alındığı an değil, ödemenin alındığı andan kodun müşteriye ulaştığı ana kadar geçen o birkaç saniyedir. O aralıkta sistemin nasıl davrandığını belirleyen şey ise iki sıkıcı kelimedir: sipariş kuyruğu ve idempotency.
Sıkıcı oldukları için de kimse sana anlatmaz. Bir e-pin scripti tanıtılırken ekran görüntüsü verilebilecek her şey öne çıkarılır: tema, kategori yapısı, admin grafikleri. Kuyruğun ekran görüntüsü yoktur. Idempotency anahtarının vitrini olmaz. Ama günde 40 sipariş aldığında hiçbir sorun çıkarmayan bir kurgunun, kampanya gününde 400 siparişte neden dağıldığını açıklayan tek başlık tam olarak burasıdır. Bu yazıda o perdeyi aralıyoruz.
Çoğu Panel Sipariş Almıyor, Sadece Sırayla Şansını Deniyor
Basit kurgulu bir dijital ürün satış scripti şöyle çalışır: müşteri ödeme yapar, ödeme sağlayıcısı geri döner, aynı istek içinde stoktan bir kod çekilir ya da tedarikçi API'si çağrılır, sonuç ekrana basılır. Tek bir müşteri varken bu akış kusursuz görünür. Problem, bu akışın tamamının tek bir HTTP isteğinin ömrüne sıkıştırılmış olmasıdır.
Tarayıcı o isteği 30 saniyede kesebilir. Müşterinin mobil bağlantısı kopabilir. Sunucunun PHP zaman aşımı dolabilir. Tedarikçi o an 8 saniye gecikebilir. Bunların her birinde ödeme alınmış, kod tedarikçiden düşmüş, ama müşteri hiçbir şey görmemiş olur. Müşteri sayfayı yeniler, ikinci bir kod daha düşer. Akşam mutabakatta tedarikçi ekstresi 12 kod, senin panelde 9 satış yazar. Aradaki üç kod kaybolmamıştır; sistem onları kimseye ait olmayan bir boşluğa teslim etmiştir.
Idempotency Nedir ve Kasadan Parayı Tam Olarak Nasıl Alır?
Idempotency tek cümleyle şudur: aynı işlemi kaç kez tetiklersen tetikle, sonuç bir kez gerçekleşir. Pratikte her sipariş oluşturulurken benzersiz bir anahtar üretilir; ödeme dönüşü, yeniden deneme, webhook tekrarı, müşterinin sayfa yenilemesi — hepsi aynı anahtarla gelir. Sistem o anahtarı daha önce işlediyse yeni kod düşmez, ilk sonucu geri verir.
Bu olmadığında üç maliyet birden oluşur. Birincisi doğrudan zarar: tek ödeme karşılığında iki kod teslim edilir, ikinci kodun alış bedeli senin cebinden çıkar. İkincisi itibar: aynı kodu iki müşteriye teslim eden sistemlerde "kod kullanılmış" şikâyeti gelir ve bunu kanıtlamak neredeyse imkânsızdır. Üçüncüsü ise zaman: her mutabakat farkı, saatlerce ekstre karşılaştırması demektir. Çift teslimatın gerçek fiyatı kodun maliyeti değil, o kodun peşinde geçen mesai saatidir.
| Senaryo | Kuyruk + Idempotency Yokken | Varken | Etki |
|---|---|---|---|
| Müşteri ödeme sonrası sayfayı yeniler | İkinci kod düşer | İlk kod tekrar gösterilir | Mükerrer maliyet sıfırlanır |
| Ödeme sağlayıcısı webhook'u 3 kez gönderir | 3 sipariş, 3 kod | 1 sipariş, 1 kod | Mutabakat farkı bitişi |
| Tedarikçi API'si 10 sn gecikir | Zaman aşımı, sipariş kayıp | Kuyrukta bekler, sonra teslim | Sipariş kaybı engellenir |
| Eşzamanlı 200 sipariş | Sunucu kilitlenir, stok çakışır | Sıralı işlenir, stok kilitli | Kampanya günü ayakta kalır |
| Tedarikçi bakiyesi tükenir | Sessiz hata, "başarılı" ekranı | Sipariş beklemede, uyarı | Şikâyet yerine bilgilendirme |
| Sunucu işlem ortasında yeniden başlar | Yarım sipariş, kimse bilmez | Kuyruk kaldığı yerden devam | Veri tutarlılığı korunur |
Kampanya Günü Kuyruksuz Bir Sistemde Tam Olarak Ne Olur?
Kuyruk, siparişleri yavaşlatmak için değil, yük ile teslimatı birbirinden ayırmak için vardır. Kuyruklu bir e-pin satış yazılımı ödeme onayını aldığı anda siparişi "işlenecek" olarak kaydeder ve müşteriye hemen cevap döner. Kod çekme işini arka planda çalışan işçi süreçler yapar. Böylece tedarikçinin 6 saniyelik gecikmesi, web sunucusunun 6 saniye bloke olması anlamına gelmez.
Kuyruk olmadığında aynı anda gelen 200 sipariş, aynı anda 200 açık bağlantı ve 200 bekleyen veritabanı kilidi demektir. Sunucu belleği dolar, yeni ziyaretçi siteye giremez ve ironik biçimde en çok satış yaptığın saatte site kapanır. Daha kötüsü: kilitlenme sırasında stok tablosundan aynı kodu iki farklı işlem okuyabilir. Bu, satır seviyesinde kilit ve tek yönlü durum geçişi olmadan kaçınılmazdır.
Teslimat Hatalarının Gerçek Kaynak Dağılımı
- Mükerrer istek / idempotency yokluğu 45%
- Tedarikçi gecikmesi ve zaman aşımı 25%
- Eşzamanlı stok çakışması 20%
- Diğer (yanlış ürün eşleşmesi vb.) 10%
Tedarikçi API'si Bozulduğunda Kuyruk Seni Nasıl Kurtarır?
E-pin işinde tedarikçi kesintisi istisna değil, rutindir. Önemli olan kesintinin olup olmaması değil, kesinti anında sisteminin ne yaptığıdır. Kuyruklu bir kurguda sipariş kaybolmaz; başarısız deneme sayısı artırılır, artan aralıklarla tekrar denenir ve belirli bir eşikten sonra sipariş "manuel müdahale" durumuna alınıp sana bildirilir. Müşteri ise "siparişin hazırlanıyor" mesajı görür.
Kuyruksuz kurguda aynı kesinti üç farklı sonuç üretir ve hangisinin olduğunu asla bilemezsin: ödeme alındı kod gelmedi, kod geldi kayıt düşmedi, ya da her ikisi de yarım kaldı. Belirsizlik, zararın kendisinden daha pahalıdır; çünkü belirsizliği çözmek için her seferinde insan gücü harcarsın. İyi bir epin yazılım mimarisi sana her siparişin hangi adımda olduğunu tek ekranda gösterir.
Satıcıya şunu sor: "Aynı ödeme bildirimi üç kez gelirse kaç kod düşer?" Cevap net bir 'bir tane, çünkü idempotency anahtarı var' değilse, geri kalan özellik listesini okumaya gerek yok.
Pinova'da Bu Katman Nasıl Kurgulanmış?
Pinova bir e-pin satıcısı değil; e-pin ve dijital ürün satan işletmelerin kullandığı lisanslı bir satış yönetim yazılımıdır. Tam bu yüzden mimarisinde vitrin kadar teslimat hattına yer ayrılmıştır. Sipariş oluşturma ile teslimat birbirinden ayrılmış durumda: ödeme onayı siparişi kuyruğa yazar, arka plan işçileri kodu çeker, durum geçişleri tek yönlüdür ve geriye dönmez.
Her sipariş kendi benzersiz anahtarını taşır; tekrar eden ödeme bildirimleri, sayfa yenilemeleri ve yeniden denemeler aynı anahtarla eşleşip tekrar teslimat üretmez. Stok kodları satır kilidiyle rezerve edilir, teslim edilene kadar başka hiçbir işlem o kodu göremez. Tedarikçi tarafında hata alan siparişler artan aralıklı yeniden denemeye girer; eşik aşılırsa manuel havuza düşer ve panelde işaretlenir. Detaylı teknik başlıkları özellikler bölümünde inceleyebilirsin.
Kendi Sistemini Acımasızca Test Etmenin Yolu
Bu katmanı iddiadan değil testten öğrenirsin. Aşağıdaki kontrol listesi, kullandığın ya da satın almayı düşündüğün e-pin satış scripti üzerinde yarım günde uygulanabilir. Her satırı bizzat dene; pazarlama metnine güvenme.
| Test | Nasıl Yapılır | Geçme Kriteri | Önem |
|---|---|---|---|
| Çift tıklama testi | Ödeme onay sayfasını hızla 5 kez yenile | Tek kod, tek kayıt | Kritik |
| Webhook tekrarı | Aynı bildirimi 3 kez manuel gönder | Tek sipariş oluşur | Kritik |
| Gecikme simülasyonu | Tedarikçi adresini erişilemez yap | Sipariş beklemede kalır | Kritik |
| Eşzamanlılık | Aynı stoklu ürüne 20 paralel sipariş | Hiçbir kod iki kez çıkmaz | Kritik |
| Yeniden başlatma | İşlem sırasında servisi durdur-başlat | Kuyruk kaldığı yerden devam | Yüksek |
| Mutabakat | Gün sonu tedarikçi ekstresiyle karşılaştır | Fark sıfır | Yüksek |
| Görünürlük | Bekleyen siparişleri panelde ara | Tek ekranda listelenir | Orta |
Teslimat hattını şansa bırakma
Kuyruk, idempotency ve stok kilidi hazır gelen lisanslı bir altyapıyla başla. Fiyat ve paket seçeneklerini buradan karşılaştırabilirsin.
Günde 30 siparişim var, bana kuyruk gerekir mi?
Kuyruğun faydası hacimle değil belirsizlikle ilgilidir. 30 siparişte bile tek bir çift teslimat ya da kayıp sipariş, saatlerce mutabakat demektir. Ayrıca büyüdüğünde mimariyi değiştirmek, baştan doğru kurmaktan çok daha pahalıdır.
Idempotency'yi sonradan eklemek mümkün mü?
Teknik olarak mümkün ama zahmetli. Sipariş tablosuna benzersiz anahtar, ödeme dönüşlerine anahtar taşıma ve tüm teslimat yollarının tek noktadan geçmesi gerekir. Dağınık kurgularda bu, yeniden yazmaya yakın bir iş çıkarır.
Kuyruk müşteriyi bekletir mi?
Tam tersi. Müşteri ödeme sonrası anında cevap alır, kod hazır olduğunda ekranda ve e-postada görünür. Kuyruksuz kurguda müşteri tedarikçinin gecikmesi kadar boş ekrana bakar.
Paylaşımlı hostingde arka plan işçileri çalışır mı?
Çoğu paylaşımlı planda zamanlanmış görev desteği vardır ve kısa aralıklı tetikleme ile kuyruk işlenebilir. Yoğun hacimde ise sürekli çalışan işçi süreçleri için kendi sunucun daha sağlıklı olur.
Teslimat mimarisi, satın alma kararının en az konuşulan ama faturası en yüksek başlığıdır. Bir sistemin bu katmanı doğru kurup kurmadığını da en hızlı şekilde elleyerek anlarsın: sipariş oluştur, sayfayı defalarca yenile, tedarikçi hatasını tetikle ve panelde neler olduğunu izle. Pinova'nın kuyruk, idempotency ve stok kilidi davranışını kendi gözünle görmek için canlı demo üzerinden bu testleri birebir uygulayabilir, sonra lisans adımına geçebilirsin.