Kampanya duyurusunu yaptın, trafik geldi, siparişler düşüyor. Panel açık, her şey yolunda görünüyor. Sonra bir müşteri yazıyor: "Ödemeyi yaptım, 14 dakika oldu, kod gelmedi." Bakıyorsun sipariş orada, durumu "işleniyor". Çoğu satıcı bu anda sunucuyu suçlar, bazıları ödeme sağlayıcısını. Gerçek sebep neredeyse her zaman aynı: teslimat işleri bir kuyruğa girmiş ve o kuyruğu kimse yönetmiyor.
Kuyruk, bir e-pin satış scripti içinde en çok göz ardı edilen ama satış hacmini en doğrudan sınırlayan parçadır. Çünkü kuyruk yoksa sistem trafikte kilitlenir, kuyruk varsa ama sırası yönetilmiyorsa sistem trafikte sessizce yavaşlar. İkincisi daha tehlikelidir; hata mesajı vermez, sadece müşteri kaçırır. Bu yazıda kuyruğun nasıl çalıştığını, kaç işçiyle döndüğünü, hangi işin öne geçmesi gerektiğini ve tıkandığında ne yapılacağını anlatıyorum.
Kuyruk Aslında Bir Bekleme Odası Değil, Bir Sözleşme
Teslimat kuyruğunu "işler sıraya giriyor" diye düşünmek eksik bir resim verir. Kuyruk esasen şu sözü verir: bu iş kaybolmayacak, en az bir kez çalıştırılacak ve sonucu kayda geçecek. Bu sözün karşılığında senden bir şey ister — işin tekrar çalıştırılmaya dayanıklı olması. Yani aynı teslimat görevi iki kez işlenirse ikinci kez zarar vermemeli. Kuyruk ile tekillik kontrolü bu yüzden ayrılmaz ikizdir; kuyruk kurup tekilliği atlayan bir kurulum, sorunu çözmek yerine büyütür.
İkinci nokta: kuyruk eşzamanlılığı yok etmez, yönetilebilir hale getirir. Ödeme bildirimi geldiği anda teslimat yapmaya çalışan bir epin yazılım kurulumunda 200 sipariş 200 eşzamanlı iş demektir; veritabanı boğulur, posta sunucusu sınırı aşar, tedarikçi API'si seni kısıtlar. Kuyruk aynı 200 işi dörtlü gruplar halinde akıtır. Toplam süre biraz uzar ama hiçbir iş düşmez. Satıcı için önemli olan en hızlı teslimat değil, en yüksek tamamlanma oranıdır.
Kaç İşçi Çalıştırmalısın ve Fazlası Neden Zarar?
İşçi, kuyruktan iş alıp yürüten süreçtir. Sayısını belirlerken bakılacak şey sunucunun çekirdek sayısı değil, en yavaş dış bağımlılığın kapasitesidir. Teslimatın içinde bayi API çağrısı varsa ve o API saniyede 5 istek kabul ediyorsa, 20 işçi çalıştırmak kuyruğu hızlandırmaz; hata oranını artırır, tekrar denemeleri çoğaltır ve kuyruğu daha da uzatır. Buna "tekrar deneme çığı" diyorum ve genellikle işçi sayısı iyi niyetle artırıldığı için başlar.
Pratik yaklaşım şu: en yavaş bağımlılığın güvenli hızını ölç, işçi sayısını onun altında tut, sonra kuyruk uzunluğunu izle. Kuyruk sürekli boşalıyorsa kapasiten yeterli. Kuyruk sürekli büyüyorsa önce işin kendisini hızlandır — gereksiz sorguları, senkron posta gönderimini, teslimat anında üretilen PDF'i çıkar — ardından işçiyi artır. Sağlam bir dijital ürün satış yazılımı bu ölçümleri sana panelde gösterir; göstermiyorsa körlemesine ayar yapıyorsun demektir.
| İş türü | Öncelik | Hedef süre | Başarısızlıkta davranış |
|---|---|---|---|
| Stoktan hazır kod teslimi | Yüksek | 5 saniye altı | 3 kez artan aralıkla dene |
| Tedarikçi API'sinden kod çekme | Yüksek | 30 saniye altı | 5 kez dene, sonra elle onaya düş |
| Teslimat e-postası / mesajı | Orta | 2 dakika altı | 6 kez dene, kanal değiştir |
| Fatura ve belge üretimi | Düşük | 15 dakika altı | Sessizce yeniden kuyruğa al |
| Rapor ve istatistik yenileme | En düşük | Gece penceresi | Bir sonraki pencereye bırak |
Öncelik Yoksa En Değersiz İş En Değerli Müşteriyi Bekletir
Tek şeritli kuyruğun en sinsi yan etkisi şudur: gece raporu üretimi ile bekleyen bir müşterinin kodu aynı sırada durur. Rapor 40 saniye sürer, müşteri 40 saniye bekler. Çözüm, işleri sınıflandırıp ayrı şeritlere koymaktır. Teslimat şeridi her zaman öncelikli olmalı; bildirim şeridi ondan sonra gelmeli; belge ve rapor şeritleri arta kalan kapasiteyi kullanmalı.
Öncelik kurgusunun ikinci boyutu müşteri tarafıdır. Bayi siparişleri genelde çok kalemli ve uzun sürelidir; tek kalemli perakende siparişin arkasında beklemesi kimseyi üzmez, tersi büyük hayal kırıklığı yaratır. Bu yüzden iyi bir e-pin satış yazılımı kuyruğa "kalem sayısı" ve "tahmini süre" bilgisini de katar, uzun işleri ayrı şeride alır. Buna adil sıralama denir ve etkisi ortalama bekleme süresinde değil, en kötü durum bekleme süresinde görülür — müşteri deneyimini belirleyen de tam olarak o.
Kuyrukta geçen sürenin dağılımı (yoğun saat ölçümü)
- Dış API yanıtı bekleme 45%
- Bildirim gönderimi 25%
- Veritabanı kilit bekleme 20%
- Görev alma ve kayıt 10%
Tekrar Deneme Mantığı: Israrcı Olmak ile Saldırmak Arasındaki Çizgi
Bir iş başarısız olduğunda hemen tekrar denemek çoğu zaman yanlıştır. Tedarikçi zaten yoğun olduğu için hata verdiyse, 50 milisaniye sonra aynı isteği göndermek durumu kötüleştirir. Doğru yöntem artan aralıklı tekrar denemedir: 5 saniye, 15 saniye, 45 saniye, 2 dakika şeklinde açılan bir merdiven. Üstüne küçük bir rastgelelik ekle, böylece aynı anda başarısız olan yüz iş aynı anda geri dönmez.
İkinci kural: tekrar denemenin bir sonu olmalı. Sınırsız deneme, kuyruğu asla boşalmayan zombi işlerle doldurur. Belirlediğin sınıra ulaşan iş "ölü mektup kutusu" dediğimiz ayrı bir listeye düşer; orada insan gözü tarafından incelenir. Bu liste boşsa sistemin sağlıklıdır, doluyorsa sana neyin bozuk olduğunu adres adres söyler. Pek çok e-pin yazılımı kurulumunda bu liste hiç yoktur ve başarısız işler sessizce kaybolur — satıcı kaybı ancak müşteri yazdığında öğrenir.
Panelde izlemen gereken metrik kuyruk uzunluğu değil, en eski bekleyen işin yaşı. Uzunluk dalgalanır ve yanıltır; en eski işin yaşı 3 dakikayı geçtiyse sistemde gerçek bir tıkanma var.
Kuyruk Durduğunda Fark Etmenin Tek Yolu: Ölü Adam Anahtarı
İşçi süreçleri sessizce ölür. Sunucu yeniden başlar, bellek sınırı aşılır, güncelleme sırasında süreç kapanır ve kimse haber vermez. Kuyruk dolar, siparişler bekler, panel normal görünür. Bunun tek çaresi düzenli kalp atışıdır: her işçi çalıştığını belirten bir zaman damgası yazar, ayrı bir denetim görevi bu damgaların tazeliğini kontrol eder, tazelik bozulduğunda sana bildirim gider.
Bu denetimi kurarken bir de tersini düşün: işçi ayakta ama iş üretmiyor olabilir. Sıfır iş tamamlanmış ama kuyrukta 80 iş bekliyorsa uyarı üretilmeli. Bir dijital ürün satış scripti için bu iki alarm, gecelik sipariş kaybının önündeki en güçlü barikattır. Maliyeti neredeyse sıfır, getirisi uyandığında karşılaşmadığın kriz.
| Kontrol maddesi | Sağlıklı değer | Nasıl test edilir |
|---|---|---|
| Teslimat ve bildirim ayrı şeritte mi | Evet | Rapor görevini başlat, teslimat hızını ölç |
| En eski bekleyen iş yaşı izleniyor mu | 3 dakika altı | Panelde metriği ara, yoksa ekle |
| Tekrar deneme aralığı artıyor mu | Kademeli | Tedarikçi API'sini kapat, günlükleri izle |
| Deneme üst sınırı ve ölü liste var mı | Var | Kasıtlı bozuk iş oluştur, nereye düştüğünü gör |
| İşçi kalp atışı kaydı tutuluyor mu | 60 saniyede bir | İşçiyi durdur, uyarı gelmesini bekle |
| Aynı iş iki işçiye düşebiliyor mu | Düşmemeli | İşçi sayısını artır, çift teslimat kontrol et |
| Kuyruk sunucu yeniden başlarsa hayatta mı | Evet | Sunucuyu yeniden başlat, bekleyen işleri say |
Kuyruğunu tahminle değil ölçümle yönet
Pinova; öncelikli şeritler, artan aralıklı tekrar deneme, ölü mektup kutusu ve işçi kalp atışı izlemeyi hazır getiren lisanslı bir e-pin satış yönetim yazılımıdır. Hacmine uygun paketi fiyat sayfasından seçebilirsin.
Kuyruk için ayrı bir sunucu şart mı?
Şart değil. Orta hacimde veritabanı tabanlı bir kuyruk ve zamanlı görevler fazlasıyla yeter. Ayrı altyapı, saniyede onlarca teslimat yaptığın noktada anlam kazanır.
İşçi sayısını artırınca teslimat neden yavaşladı?
Muhtemelen en yavaş bağımlılığın kapasitesini aştın. Tedarikçi ya da posta sunucusu seni kısıtlamaya başlar, hatalar artar, tekrar denemeler kuyruğu şişirir. Sayıyı düşürüp işin kendisini hafiflet.
Müşteri beklerken ne göstermeliyim?
Belirsiz bir yükleniyor animasyonu değil, durum ve tahmini süre. "Ödeme onaylandı, kod hazırlanıyor, tahmini 40 saniye" cümlesi destek talebi sayısını belirgin şekilde düşürür.
Ölü mektup kutusundaki işleri ne yapacağım?
Sebebe göre ayır: tedarikçi arızası geçicidir, toplu yeniden kuyruğa al. Hatalı ürün eşleşmesi kalıcıdır, önce eşleşmeyi düzelt sonra çalıştır. Kutuyu boşaltmadan kapatma.
Kuyruk yönetimi görünmez bir iştir; iyi çalıştığında kimse fark etmez, bozulduğunda her müşteri fark eder. Kendi kurulumunda en eski bekleyen iş yaşını ve ölü liste doluluğunu izlemeye başlamak, bu görünmezliği ölçülebilir hale getirmenin en hızlı adımıdır. Nasıl bir panelde göründüğünü merak ediyorsan canlı demo üzerinden kuyruk ekranlarını gezebilir, özellik listesiyle kendi sistemini karşılaştırabilirsin.