Epin Yazılımında Bildirim E-Postası Neden İki Kez Gidiyor? Müşterini Sinirlendiren Bu Tekrarın Arkasındaki Kuyruk Hatasını Kimse Anlatmıyor

Çoğu satıcı aynı bildirimin iki kez gitmesini zararsız bir kozmetik sorun sanır. "Müşteri iki mail almış, ne olacak" der ve listenin dibine atar. Oysa e-pin gibi teslimatı koda dayanan bir işte aynı sipariş için iki teslimat maili gitmesi, müşterinin kafasında "acaba iki kez mi ödeme çekildi" sorusunu doğurur ve destek kanalına bedava bir ticket yaratır. Daha kötüsü, bu tekrar deseni posta sağlayıcılarının gözünde itibar puanını düşürür.

Bu yazıda çift gönderimin neden neredeyse hiçbir zaman "mail sunucusunun hatası" olmadığını, hangi beş farklı mekanizmanın aynı görüntüyü ürettiğini ve sağlam kurgulanmış bir e-pin satış scriptinin bunu hangi tek kavramla çözdüğünü anlatacağım. O kavramın adı tekrarsızlık; yani aynı olayın kaç kez tetiklendiğinden bağımsız olarak sonucun tek olması.

Ödeme sağlayıcısı aynı bildirimi bilerek iki kez gönderir

Bu, en sık karşılaşılan ve en çok yanlış anlaşılan nedendir. Ödeme altyapıları sana işlem sonucunu bildirirken "ulaştı mı" garantisini yanıt koduna bakarak verir. Senin sunucun yavaş cevap verdiyse, 200 dışında bir kod döndürdüyse ya da yanıt zaman aşımına uğradıysa sağlayıcı bildirimi tekrar gönderir. Bu bir arıza değil, bilinçli bir tasarım kararıdır; amaç hiçbir ödemenin kaybolmamasıdır.

Sorun, senin tarafında o ikinci bildirimin ilkiyle aynı olduğunun anlaşılmamasıdır. Kod "ödeme onaylandı" görür, siparişi tekrar işler ve teslimat mailini tekrar yollar. Çözüm sağlayıcıyı susturmak değil; gelen her bildirime ait benzersiz işlem kimliğini bir tabloya benzersiz indeksli olarak yazmak ve daha önce işlenmişse sessizce başarılı cevap dönmektir. Bu tek dokunuş, çift teslimat riskini de kapatır.

Aynı olaya iki kanca bağlanmışsa mail iki kez üretilir

İkinci sık neden, olay dinleyicilerinin çoğaltılmasıdır. Bir dijital ürün satış yazılımında "sipariş tamamlandı" olayına genelde birden fazla yerden bağlanılır: çekirdek modül, bir eklenti, bir de sonradan yazılmış özel entegrasyon. Her biri kendi bildirim çağrısını yapar. Tek tek bakıldığında hepsi doğrudur; birlikte çalıştıklarında müşteri iki mail alır.

Bunu teşhis etmek şaşırtıcı derecede kolaydır. Gönderim fonksiyonuna geçici olarak çağrı yığınını loglayan bir satır ekle. İki farklı dosyadan çağrı geliyorsa neden ortadadır. Kalıcı çözüm, bildirim üretimini tek bir merkezî servise toplamak ve modüllerin doğrudan mail göndermesini yasaklamaktır. Bildirim üretimi tek kapıdan geçmiyorsa, o kapı er ya da geç ikiye çıkar.

Kuyruk işçilerinin üst üste binmesi: en sinsi senaryo

Bildirimleri kuyruğa alıp zamanlanmış görevle gönderiyorsan, görev aralığın işin süresinden kısaysa bir felaket reçetesi hazırlamışsın demektir. Beş dakikada bir çalışan bir görev, altı dakika süren bir yığını işlerken ikinci kopya başlar ve aynı kayıtları okur. İkisi de "bu mail gönderilmedi" görür, ikisi de gönderir.

Doğru kurgu iki parçadan oluşur. Birincisi, aynı anda yalnızca tek bir işçinin çalışmasını garanti eden bir kilittir. İkincisi, kaydın durumunu gönderim öncesinde işaretlemektir. Kayıt önce "işleniyor" olarak damgalanır, sonra mail gönderilir, sonra "gönderildi" yapılır. Sıralamayı tersine çevirdiğinde, yani önce gönderip sonra işaretlediğinde, arada yaşanan her kesinti bir tekrar demektir.

SMTP tarafı: mesaj gitti mi gitmedi mi belirsizliği

Posta sunucusuna bağlanıp mesajı teslim ettikten sonra bağlantı kopabilir. Kütüphane "teslim edildi" onayını alamadığı için hatayı yukarı fırlatır, senin kod da mantıklı davranıp yeniden dener. Ama mesaj aslında karşı tarafa ulaşmıştır. Sonuç: müşteri iki mail alır, senin loglarında ise bir başarısızlık ve bir başarı görünür. Bu yüzden log'a bakıp "bir kez gönderilmiş" demek yanıltıcıdır.

Bu belirsizliği tamamen yok edemezsin, ama etkisini sıfırlayabilirsin. Her bildirime sabit ve öngörülebilir bir mesaj kimliği üret; sipariş numarası ve bildirim türünden türetilmiş bir değer idealdir. Aynı kimlikle ikinci kez gönderim denendiğinde birçok posta sunucusu mesajı tekilleştirir. Üstüne bir de gönderim kaydında benzersiz indeks varsa, yeniden deneme veritabanı seviyesinde reddedilir.

Neden "sonra bakarız" demek pahalıya patlıyor?

Tekrarlı bildirimin ilk maliyeti destek yüküdür ama asıl maliyet teslim edilebilirliktedir. Posta sağlayıcıları aynı alıcıya kısa aralıkla giden benzer içerikleri düşük kaliteli gönderim işareti olarak yorumlar. Bugün gereksiz bir tekrar olan şey, üç ay sonra teslimat mailinin doğrudan spam klasörüne düşmesine yol açar. E-pin işinde teslimat mailinin ulaşmaması, doğrudan iade talebi demektir.

İkinci maliyet muhasebedir. Bildirim tekrarı çoğu zaman yalnız başına gelmez; altında yatan sebep sipariş işleme mantığının da iki kez çalışmasıdır. Bunu zamanında yakalamazsan bir gün aynı stok kodunun iki farklı müşteriye gittiğini fark edersin. Özellikler sayfasında teslimat ve bildirim akışının nasıl tek kapıdan yürütüldüğünü inceleyebilirsin.

Sağlam bir kurulum bu işi nasıl bitirir?

Pinova tarafında bildirim üretimi ile bildirim gönderimi ayrı iki adımdır. Sistem önce "şu sipariş için şu türde bir bildirim üretilecek" kaydını benzersiz anahtarla oluşturur; gönderim bu kaydın üzerinden yürür. Ödeme sağlayıcısı aynı bildirimi beş kez gönderse bile üretilen kayıt tektir, dolayısıyla gönderim de tektir.

Bunun üstüne yönetici tarafında görünür bir bildirim günlüğü gelir: hangi mail, hangi siparişe, hangi saatte, hangi durumla gitti. Müşteri "mail gelmedi" dediğinde tahmin yürütmezsin; kaydı açar, durumu görür ve gerekirse tek tuşla yeniden gönderirsin. Fiyat bölümünde hangi paketin ne kadar günlük geçmişi sakladığını görebilirsin.

Bildirim akışı, bir e-pin sisteminin kalitesini dışarıdan en hızlı ele veren yerdir; çünkü müşteri kodu değil, gelen maili görür. Tekrarsızlığın gerçekten kurulu olup olmadığını anlamanın en dürüst yolu sistemi çalışırken izlemektir. canlı demo üzerinden bir test siparişi oluşturup bildirim günlüğünün nasıl tuttuğuna bak, sonra paketleri karşılaştır.