Çoğu e-pin satıcısı sistemini şöyle kurar: müşteri öder, ödeme sağlayıcı "onaylandı" der, aynı saniyede stoktan kod çekilir ve ekrana basılır. Kulağa temiz geliyor, hatta hızlı görünüyor. Ama bu kurgu satışı ve teslimatı tek bir nefese sıkıştırdığı için ilk ciddi yoğunlukta çatlar. Tedarikçi API'si 800 milisaniye gecikirse müşteri ödeme ekranında bekler; 30 saniye gecikirse web sunucusu zaman aşımına düşer ve müşteri parasını ödediği halde eli boş kalır. Sen de gece yarısı manuel kod arayan bir operatöre dönüşürsün.
Sanılanın aksine bu bir hız problemi değil, bir mimari problemidir. Olgun bir e-pin satış scripti teslimatı satışın içinde değil, satışın arkasında yapar. Arada bir kuyruk vardır: satış tarafı yalnızca "bu siparişin teslim edilmesi gerekiyor" kaydını bırakır ve müşteriye anında yanıt döner. Teslimatı arka planda çalışan işçiler üstlenir. Bu yazıda o ayrımı neden yapman gerektiğini, yapmadığında tam olarak neyi kaybettiğini ve kendi dijital ürün satış yazılımı tarafında bunu nasıl kuracağını sırasıyla anlatıyorum.
Ödeme Onayı Geldiği Anda Kod Göndermek Neden En Pahalı Alışkanlığın?
Ödeme onayı ile teslimatı aynı isteğe bağladığında, müşterinin tarayıcısı ile tedarikçinin sunucusu arasına görünmez bir zincir kurmuş olursun. O zincirin en zayıf halkası senin değil, tedarikçinin tarafındadır. Tedarikçi bakım moduna geçtiğinde, kotanı doldurduğunda ya da sadece yavaşladığında müşteri bunu "site bozuk" olarak okur. Oysa site ayakta, sadece yanlış yerde bekliyor.
İkinci sorun daha sinsi: zaman aşımı anında istek kesilir ama tedarikçi tarafındaki işlem kesilmez. Yani kod satın alınmış, senin veritabanına yazılmamış olur. Sabah stok sayımı yaptığında bir kodun kayıp olduğunu görürsün ve nedenini bulamazsın. Kuyruk mimarisi tam olarak bu boşluğu kapatır: teslimat girişimi kendi kaydına sahip bağımsız bir iş olur, sonucu ne olursa olsun bir yere yazılır. Satış tarafı ise saniyenin onda birinde biter, çünkü tek işi siparişi kaydetmek ve kuyruğa not bırakmaktır.
Kuyruk Dediğimiz Şey Aslında Bir Sabır Sözleşmesi mi?
Kuyruk, karmaşık bir altyapı değil; bir sözleşmedir. Satış tarafı şunu taahhüt eder: "Bu siparişi kaybetmeyeceğim." Teslimat tarafı şunu taahhüt eder: "Bu işi en fazla bir kez başarıyla tamamlayacağım." Teknik olarak bunun için devasa bir mesaj kuyruğu sunucusuna ihtiyacın yok. Tek bir tablo ve disiplinli bir işçi döngüsü çoğu satıcı için fazlasıyla yeterlidir.
Pratikte tabloda şu alanlar bulunur: sipariş kimliği, durum, deneme sayısı, bir sonraki deneme zamanı, kilit sahibi ve son hata mesajı. İşçi süreç her turda "zamanı gelmiş, kilitsiz" işleri atomik bir güncellemeyle kendine kilitler. Bu kilit olmadan iki işçi aynı siparişi aynı anda alır ve müşteriye iki kod gider. Kilitleme, kuyruğun en kritik ve en çok ihmal edilen parçasıdır. Modern bir epin yazılım kurgusunda bu kilit veritabanı seviyesinde, uygulama kodunun iyi niyetine bırakılmadan uygulanır. Pinova'nın teslimat katmanında da mantık budur; detayları özellikler bölümünde görebilirsin.
Tedarikçi Çöktüğünde Senin Siten Neden Birlikte Çöküyor?
Kuyruksuz bir kurulumda tedarikçi yavaşladığında PHP işçileri birer birer meşgul olur. Onuncu yavaş istekte havuz dolar, on birinci ziyaretçi ana sayfayı bile açamaz. Yani tek bir ürünün tedarikçisi, tüm kataloğunun satışını durdurur. Bu, işletme açısından kabul edilemez bir bağımlılıktır.
Çözüm iki katmanlıdır. Birincisi kuyruk: yavaş iş arka planda beklerken ön yüz hiç etkilenmez. İkincisi devre kesici mantığı: bir tedarikçi üst üste belirli sayıda hata verirse, o tedarikçiye ait işler bir süre hiç denenmez, otomatik olarak beklemeye alınır. Böylece hem tedarikçinin sistemini boş yere yormazsın hem de kuyruğun tıkanmasını engellersin. Devre açıldığında ise biriken işler kontrollü bir hızla akmaya başlar. Bir dijital ürün satış scripti için bu davranış, tek başına aylık ciro farkı yaratır.
| Senaryo | Senkron teslimat (kuyruksuz) | Kuyruklu teslimat |
|---|---|---|
| Tedarikçi 20 sn gecikti | Müşteri bekler, zaman aşımı riski | Sipariş "hazırlanıyor", sayfa anında döner |
| Tedarikçi tamamen kapalı | Ödeme alınır, teslimat kaybolur | İş kuyrukta bekler, açılınca teslim edilir |
| Aynı anda 200 sipariş | Sunucu havuzu dolar, site yavaşlar | İşçi sayısı kadar paralel, ön yüz etkilenmez |
| Ağ hatası ortada kesildi | Kod satın alınmış ama kayıtsız | Deneme kaydı durur, mutabakat yakalar |
| Manuel müdahale gereği | Sık, gece yarısı dahil | Nadir, sadece ölü harf kuyruğunda |
Aynı Kodu İki Kez Göndermenin Matematiği Sandığından Acı
Kuyruk kurunca yeni bir risk doğar: tekrar deneme. Bir iş başarısız göründüğü için tekrar denendiğinde, aslında ilk denemede başarılı olmuş olabilir. Sonuç: aynı müşteriye iki kod, ya da daha kötüsü iki farklı müşteriye aynı kod. Bunun maliyeti sadece kodun bedeli değildir; ürünün itibarı ve tedarikçiyle ilişkin de zarar görür.
Çözüm idempotency, yani tekrarlanabilirlik güvencesidir. Her teslimat girişimine sipariş kimliğinden türeyen sabit bir anahtar verirsin ve tedarikçiye her denemede aynı anahtarı gönderirsin. Tedarikçi bu anahtarı daha önce gördüyse yeni satın alma yapmaz, eski sonucu döner. Tedarikçin böyle bir başlık desteklemiyorsa yerel savunma kurarsın: teslimat kaydını yazmadan önce siparişe tekil bir kısıt koyarsın, böylece veritabanı ikinci teslimatı fiziksel olarak reddeder.
Teslimat gecikmelerinin gerçek kaynak dağılımı
- Tedarikçi API yavaşlığı 45%
- Stok tükenmesi ve elle müdahale 25%
- Ödeme onayı bildirim gecikmesi 20%
- Sunucu ve ağ kaynaklı diğer 10%
Kuyruğu Kim İzliyor? Görünmeyen İş Yükünün Paneldeki Yeri
Kuyruk kurmanın en büyük tuzağı şudur: sorun artık müşterinin ekranında görünmez. Kuyruk tıkandığında site hâlâ hızlı çalışır, ana sayfa açılır, sipariş alınır. Sen problemi ancak müşteri yazdığında öğrenirsin. Bu yüzden kuyruk mimarisi izleme olmadan yarım kalır.
Panelde görmen gereken dört sayı var: bekleyen iş sayısı, en eski bekleyen işin yaşı, son bir saatteki başarısız deneme oranı ve ölü harf kuyruğundaki iş sayısı. Bu dördünden en kritiği ikincisidir. On bin iş beklemesi normal olabilir; ama en eski işin yaşı 15 dakikayı geçtiyse bir yerde tıkanma var. Ayrıca işçi sürecinin kendisi de izlenmelidir: sessizce ölmüş bir işçi, hata vermeyen ama satış yapmayan bir sistem demektir. Sağlıklı bir e-pin yazılımı kurgusunda işçi her turda bir "yaşıyorum" damgası bırakır ve bu damga iki dakikadan eskiyse uyarı üretilir.
Kuyruk Mimarisine Geçişi Tek Gecede Nasıl Yaparsın?
İyi haber: bu geçiş için sistemi sıfırdan yazmana gerek yok. Mevcut teslimat fonksiyonunu olduğu gibi bırakıp, çağrıldığı yeri değiştirmen yeterlidir. Ödeme onayı geldiğinde fonksiyonu doğrudan çağırmak yerine kuyruğa kayıt atarsın; işçi süreç de aynı fonksiyonu çağırır. Tek gerçek iş, fonksiyonun tekrar çağrıldığında ikinci kez satın alma yapmamasını garantilemektir.
Geçişi güvenli yapmanın yolu paralel çalıştırmadır: bir hafta boyunca kuyruğu açık tut ama teslimatı yine senkron yap, kuyruk sadece kayıt tutsun. Kayıtlar ile gerçek teslimatlar birebir uyuşuyorsa anahtarı çevirirsin. Bu yaklaşımın maliyeti yok, kazancı ise kampanya günlerinde kaybetmediğin siparişlerdir. Lisans ve paket seçeneklerini fiyat bölümünde karşılaştırabilirsin.
| Kontrol maddesi | Neden gerekli | Durum ölçütü |
|---|---|---|
| Atomik iş kilitleme | Çift teslimatı kökten engeller | İki işçi aynı işi alamıyor |
| Idempotency anahtarı | Tekrar denemede mükerrer satın alma olmaz | Anahtar sipariş kimliğinden türetiliyor |
| Artan bekleme süresi | Tedarikçiyi hata anında yormaz | 5 sn, 30 sn, 2 dk, 10 dk |
| Ölü harf kuyruğu | Sonsuz döngüyü keser, insanı çağırır | 6. denemeden sonra devreye giriyor |
| İşçi yaşam damgası | Sessiz ölümü yakalar | 2 dakikadan eskiyse uyarı |
| En eski iş yaşı alarmı | Tıkanmayı müşteriden önce görürsün | 15 dakika üstü bildirim |
İşçi sürecini cron ile her dakika tetiklemek yeterli değil; üst üste çalışan iki turun çakışmaması için dosya kilidi kullan. Aksi halde yoğun saatte onlarca işçi aynı kuyruğa saldırır.
Teslimatı satıştan ayıran hazır bir altyapı istiyorsan
Kuyruk, kilitleme, artan bekleme ve ölü harf mantığı Pinova'da kutudan çıktığı gibi çalışır. Sen sadece tedarikçini tanımlarsın.
Kuyruk için ayrı bir sunucu ya da Redis şart mı?
Hayır. Günlük birkaç bin siparişe kadar tek bir veritabanı tablosu ve kilitli bir işçi döngüsü fazlasıyla yeterlidir. Ayrı altyapıyı ancak işçi sayısını yatayda büyütmek gerektiğinde düşünürsün.
Müşteri kodunu anında görmezse dönüşüm düşer mi?
Düşmez, çünkü kuyruk çoğu siparişi bir iki saniyede tamamlar. Önemli olan sipariş sayfasının kendini otomatik yenilemesi ve "hazırlanıyor" durumunu net göstermesidir.
Ölü harf kuyruğuna düşen siparişte ne yapmalıyım?
Önce tedarikçi tarafında işlemin gerçekten olmadığını doğrula, sonra ya elle kod ata ya da iadeyi başlat. Bu kararı sistemin otomatik vermemesi doğrudur.
Mevcut scriptimi bozmadan bu yapıya geçebilir miyim?
Evet. Teslimat fonksiyonunu değiştirmeden sadece çağrıldığı yeri kuyruğa taşırsın. Bir hafta gölge modda çalıştırıp kayıtları karşılaştırmak en güvenli yoldur.
Kuyruk mimarisi kulağa mühendislik detayı gibi gelse de aslında bir işletme kararıdır: teslimatı müşterinin sabrına değil, kendi sistemine emanet etmeyi seçmektir. Bu ayrımı yapan satıcılar kampanya gecelerini telefonla değil raporla geçirir. Yapının gerçek panelde nasıl göründüğünü kendi gözünle görmek istersen canlı demo üzerinden kuyruk ekranını, deneme geçmişini ve ölü harf listesini inceleyip kendi akışınla karşılaştırabilirsin.