Çoğu satıcı teslimat gecikmesini sunucu gücüne bağlar. "Hosting yavaş", "RAM yetmiyor", "CPU yükleniyor" denir ve daha pahalı bir pakete geçilir. Ay sonunda fatura artmıştır ama teslimat hâlâ 30-40 saniye sürüyordur. Çünkü darboğaz neredeyse hiçbir zaman donanımda değildir; ödeme onayı ile kodun kullanıcıya düşmesi arasındaki iş akışının sırasındadır. Yanlış sıralanmış üç adım, en güçlü sunucuda bile saniyeleri yer.
Gerçek şu: iyi kurgulanmış bir dijital ürün satış scriptinde teslimat, ödeme onayının gelmesinden itibaren 1-3 saniye içinde tamamlanır. Bunu başaran sistemlerin donanımı özel değildir; yaptıkları şey, uzun süren işleri teslimat yolundan çıkarmaktır. Bu yazıda e-posta gönderimi, fatura üretimi, tedarikçi sorgusu ve log yazımı gibi adımların teslimat zincirinden nasıl ayrılacağını, ön rezerv mantığının neden her şeyi değiştirdiğini tek tek konuşacağız.
Ödeme onayından sonra sistemin içinde tam olarak ne oluyor?
Tipik bir kurulumda sıra şöyledir: ödeme sağlayıcısından callback gelir, sipariş güncellenir, stoktan kod çekilir, fatura oluşturulur, PDF üretilir, e-posta gönderilir, SMS gönderilir, log yazılır ve ancak bundan sonra kullanıcıya "teslim edildi" ekranı gösterilir. Bu zincirde PDF üretimi tek başına 2-4 saniye, SMTP bağlantısı 1-6 saniye, SMS sağlayıcı API'si 0,5-3 saniye tutabilir. Kullanıcı, kendisini hiç ilgilendirmeyen dört işlemin bitmesini bekler. Oysa onun tek istediği kodu görmektir. Teslimat yolunda sadece kodun kullanıcıya ulaşması için zorunlu adımlar kalmalıdır.
Kuyruk mimarisi neden bu kadar kritik?
Kuyruk, "şimdi yapılması şart olmayan" işleri arka plana atan basit bir yapıdır. Fatura, e-posta, SMS, muhasebe entegrasyonu, bildirim webhook'ları ve detaylı log yazımı kuyruğa alınır; kullanıcıya kod anında gösterilir. Kuyruğu işleyen worker saniyeler sonra o işleri sessizce tamamlar. Bu ayrım yapıldığında teslimat süresi genelde altıda birine iner. Modern bir e-pin satış yazılımı bunu varsayılan olarak yapar; eski kurulumlarda ise her şey tek bir PHP isteğinin içinde sırayla çalışır ve kullanıcı ekrana bakarak bekler.
| Adım | Tipik süre | Teslimat yolunda olmalı mı? | Doğru yeri |
|---|---|---|---|
| Ödeme doğrulama | 0,2-0,8 sn | Evet | Senkron |
| Stoktan kod ayırma | 0,05-0,3 sn | Evet | Senkron (kilitli) |
| Panelde kod gösterimi | 0,1 sn | Evet | Senkron |
| Fatura PDF üretimi | 2-4 sn | Hayır | Kuyruk |
| E-posta gönderimi | 1-6 sn | Hayır | Kuyruk |
| SMS bildirimi | 0,5-3 sn | Hayır | Kuyruk |
| Muhasebe/ERP aktarımı | 1-10 sn | Hayır | Kuyruk |
| Tedarikçi API sorgusu | 2-15 sn | Duruma göre | Ön rezerv |
Tedarikçiden anlık çekim yapıyorsan teslimatın neden hep dalgalı?
Stoğu kendinde tutmayıp her siparişte tedarikçi API'sine giden kurulumlarda teslimat süresi senin kontrolünde değildir. Tedarikçi 15 saniyede yanıt veriyorsa, müşterin 15 saniye bekler. Çözüm, ön rezerv mantığıdır: sistem satış hızına bakarak popüler ürünlerden belirli miktarda kodu önceden çeker ve yerel havuzda bekletir. Sipariş geldiğinde kod havuzdan verilir, havuz arka planda yeniden doldurulur. Böylece tedarikçinin yavaşlığı müşteriye yansımaz. Havuz eşiği ürün bazında ayarlanabilir olmalı; yavaş dönen ürünlerde büyük havuz tutmak nakdi kilitler.
Teslimat süresini oluşturan bileşenler (optimize edilmemiş kurulum)
- Senkron e-posta ve fatura üretimi 45%
- Tedarikçi API bekleme 25%
- Veritabanı kilit ve sorgu yükü 20%
- Ağ ve sunucu gecikmesi 10%
Stok kilidi olmadan hızlanmak neden tehlikeli?
Teslimatı hızlandırmak isterken en sık yapılan hata, stok çekiminde kilit mekanizmasını gevşetmektir. Aynı anda gelen iki sipariş aynı kodu alırsa, kazanacağın bir saniyenin bedeli çift satılmış bir koddur; bu da iade, itiraz ve itibar kaybı demektir. Doğru yaklaşım, kod çekimini atomik bir işlemle yapmaktır: kod satırı seçilirken "rezerve" damgası aynı sorguda basılır, ikinci istek aynı satırı göremez. Bu işlem milisaniyelerle ölçülür, yani hızdan feragat etmeden güvenlik sağlanır. Kaliteli bir epin yazılım altyapısında bu davranış varsayılandır, opsiyon değildir.
Her siparişte "ödeme onayı" ve "kod görüntülendi" damgaları arasındaki farkı milisaniye olarak kaydet. Bu tek metrik, hangi adımın seni yavaşlattığını tahmin etmeden gösterir.
Sayfa hızıyla teslimat hızı aynı şey mi?
Değil, ama alıcının gözünde birbirine karışır. Ödeme sonrası dönen sayfa ağır JavaScript yüklüyorsa, kod arka planda hazır olsa bile kullanıcı bekliyor hisseder. Bu yüzden teslimat ekranı olabildiğince sade tutulmalı, kod alanı sayfanın ilk boyanan bileşeni olmalıdır. Ayrıca "hazırlanıyor" durumundan "hazır" durumuna geçiş, sayfayı yenilemeden küçük bir yoklama ile yapılmalıdır; kullanıcıyı F5'e mecbur bırakan akışlar algılanan süreyi iki katına çıkarır. Algılanan hız, gerçek hız kadar satış etkiler.
Yoğun saatte sistem neden çöküyor, gerçekten trafik mi?
Kampanya saatlerinde yaşanan çöküşlerin büyük kısmı eşzamanlı bağlantı sayısından değil, uzun süren isteklerin PHP işçilerini işgal etmesinden kaynaklanır. Her istek 12 saniye sürüyorsa ve 20 işçin varsa, saniyede taşıyabileceğin sipariş sayısı ikiye düşer; sıradaki herkes zaman aşımı görür. İstek süresini 2 saniyeye indirdiğinde aynı donanımla altı kat kapasiteye çıkarsın. Yani kuyruk mimarisi sadece hız değil, dayanıklılık meselesidir. Sunucu yükseltmeden önce zinciri kısaltmak her zaman daha ucuzdur.
| Kontrol maddesi | Hedef değer | Öncelik |
|---|---|---|
| Ödeme onayı → kod görüntüleme süresi | < 3 sn | Kritik |
| E-posta ve fatura kuyruğa alındı mı | Evet | Kritik |
| Stok çekiminde atomik kilit | Evet | Kritik |
| Popüler ürünlerde ön rezerv havuzu | 2-3 günlük satış | Yüksek |
| Teslimat ekranında canlı durum yoklaması | Evet | Yüksek |
| Worker hata yeniden deneme politikası | 3 deneme + uyarı | Yüksek |
| Yavaş sorgu logu takibi | Haftalık | Orta |
| Zaman aşımı durumunda otomatik iade/iptal | Evet | Orta |
Saniyeleri geri kazandıran teslimat altyapısı
Pinova, kuyruk tabanlı teslimat, atomik stok kilidi ve ön rezerv havuzunu hazır sunar. Kampanya saatinde kapasiten donanımla değil mimariyle büyür.
Kuyruk kurmak için ayrı sunucu gerekir mi?
Hayır. Paylaşımlı hostingde bile veritabanı tabanlı kuyruk ve dakikalık cron ile ciddi kazanım alınır. Ayrı servis, ancak günlük sipariş hacmin binlere çıktığında anlamlı olur.
E-postayı kuyruğa alırsam müşteri geç mi haber alır?
Genellikle 5-20 saniye içinde e-posta gider ve bu süre kullanıcıyı etkilemez; çünkü kodu zaten panelde görmüştür. Kritik olan, kodun ekrana düşme anıdır.
Ön rezerv havuzu nakit bağlar mı?
Bağlar, bu yüzden havuz boyutu satış hızına göre hesaplanmalıdır. Günde 30 adet satan bir ürün için 60-90 adetlik havuz makuldür; ayda 3 satan üründe havuz tutmak gereksizdir.
Teslimat süresini nasıl ölçerim?
Ödeme onayı damgası ile kodun ilk görüntülenme damgası arasındaki farkı milisaniye cinsinden kaydet ve ortalama yerine yüzde 95'lik dilime bak. Ortalama iyi görünürken kuyruk sonundaki müşteriler kötü deneyim yaşıyor olabilir.
Teslimat süresi, dijital ürün satışında en görünür kalite işaretidir; alıcı fiyatı unutur ama 40 saniye beklediği geceyi unutmaz. Mimarinin nasıl kurulduğunu, hangi adımların kuyruğa alındığını ve teslimat ekranının nasıl davrandığını kendin denemek istersen canlı demo üzerinde bir sipariş akışını baştan sona çalıştırabilir, teknik detaylar için özellikler bölümüne göz atabilirsin.