Yazılımda e-posta ve SMS bildirimleri nasıl kurulur?

Yazılımda bildirim kurmanın doğru yolu, gönderim kodunu iş akışının içine serpiştirmek değil, olayları tek bir bildirim katmanına bildirip gönderimi o katmana bırakmaktır. İkinci kural, her bildirimin kuyruğa alınıp arka planda gönderilmesidir; kullanıcı kaydı kaydederken e-posta sunucusunu beklememelidir. Sipariş onayı, ödeme bilgisi, stok uyarısı, onay bekleyen talep, iş emri hatırlatması — bunlar aynı altyapıyı kullanır ve her biri için ayrı kod yazılan sistemler kısa sürede yönetilemez hale gelir. Bu yazıda bildirim altyapısının bileşenlerini, şablon yönetimini ve teslim takibini anlatıyoruz.

Olay, kanal ve alıcı ayrımı

Sağlam bir bildirim tasarımı üç şeyi birbirinden ayırır: ne oldu, kime gidecek, hangi kanaldan gidecek. Yazılım bir olay üretir — sipariş onaylandı, talep reddedildi, ödeme alındı. Bu olayın kimlere ve hangi kanaldan ulaşacağı kodda sabit değil, ayar tablosunda tanımlanır.

• Olay: iş akışında gerçekleşen, tekrar edilebilir biçimde adlandırılmış durum değişikliği
• Alıcı kuralı: olayın ilgilileri — kaydın sahibi, yöneticisi, ilgili rol, sabit bir adres
• Kanal: e-posta, SMS, panel içi bildirim, dış sisteme çağrı
• Şablon: kanalın diline uygun metin ve içine yerleşen alanlar

Bu ayrımın pratik getirisi şudur: yeni bir yöneticinin de sipariş bildirimini almasını istediğinizde kod değişmez, ayar değişir. Ayrımı yapmayan sistemlerde her alıcı talebi geliştirme işi olur.

Şablon yönetimi ve değişken disiplini

Şablonlar veritabanında tutulur ve yetkili kullanıcı tarafından düzenlenebilir olmalıdır. Her şablon için hangi değişkenlerin kullanılabileceği listelenir; tanımsız bir değişken yazıldığında gönderim anında boş metin çıkmaması için şablon kaydedilirken doğrulanır.

SMS tarafında uzunluk ve karakter davranışı servis sağlayıcıya göre değişir; şablonu yazarken doğrulanmış değerler yerine sağlayıcının kendi panelindeki tanımlar esas alınır. Bu yüzden şablon ekranında bir önizleme ve karakter sayacı bulundurmak, sürpriz kesilmeleri önler.

Kuyruk, tekrar deneme ve sıra

Bildirim gönderimi dış servise bağlıdır ve dış servis her zaman ayakta olmaz. Bu yüzden bildirim üretildiğinde hemen gönderilmez; bir kuyruğa yazılır ve işleyici onu sırayla alır. Böylece kullanıcı işlemi beklemez, geçici bir kesinti bildirimi yok etmez.

1. Olay üretildiğinde bildirim kaydı bekliyor durumunda açılır
2. İşleyici kaydı alır, şablonu doldurur, sağlayıcıya iletir
3. Sağlayıcı kabul ederse durum gönderildi olur, kimlik numarası saklanır
4. Geçici hata alınırsa artan aralıklarla tekrar denenir
5. Deneme sınırı aşılırsa kayıt başarısız kuyruğuna düşer ve ilgiliye görünür

Tekrar denemede iki tuzak vardır. Birincisi sonsuz deneme: geçersiz bir adrese dönüp dolaşıp gönderim denemek kuyruğu tıkar. İkincisi aynı bildirimin iki kez gitmesi; sağlayıcı kabul ettiği halde yanıt kaybolduğunda işleyici tekrar gönderebilir. Bunun önüne bildirim kaydına tekil anahtar koyarak geçilir; aynı mantığın entegrasyon tarafındaki karşılığını API, webhook ve kuyruk yazısında anlattık.

Teslim durumu ve geri bildirim

Gönderildi demek ulaştı demek değildir. E-postada gönderim sonrası dönen geri bildirimler — kabul edilmeyen adresler, kutu dolu yanıtları, şikâyet bildirimleri — izlenmezse aynı geçersiz adrese aylarca gönderim denenir ve bu, gönderen alan adının itibarına zarar verir.

• Kalıcı hata dönen adresler işaretlenir ve gönderim listesinden çıkarılır
• Geçici hatalar sayılır; eşik aşılırsa adres incelemeye alınır
• SMS tarafında sağlayıcıdan dönen durum kodları bildirim kaydına yazılır
• Panel içi bildirimlerde okundu zamanı tutulur

Bu kayıtlar destek tarafında da işe yarar. Müşteri bildirimi almadığını söylediğinde, kaydın hangi adrese ne zaman gittiği ve sağlayıcının ne yanıt verdiği tek ekrandan görülebilir.

Bildirim kayıtlarının içeriğini ne kadar sakladığınız da bir karardır. Gönderilen metnin tamamını tutmak teşhisi kolaylaştırır ama içinde ödeme bilgisi ya da kişisel veri geçen iletiler için saklama süresi sınırlanmalıdır. Pratik yol, kaydın üst bilgisini uzun süre, metin gövdesini kısa bir süre tutmaktır.

Bildirim yorgunluğu ve kullanıcı tercihi

Teknik olarak kusursuz bir altyapı, çok fazla bildirim gönderdiği için işe yaramaz hale gelebilir. Her gün yirmi e-posta alan bir kullanıcı hepsini filtreye alır ve kritik uyarı da onunla birlikte gözden kaybolur. Bunu önlemek tasarım işidir.

Birkaç pratik önlem vardır. Benzer olaylar belirli bir aralıkta tek bir özet bildirimde toplanır. Bildirimler önem derecesine ayrılır; bilgilendirme panel içinde kalır, aksiyon gerektiren uyarı e-posta ile gider, gecikmeye tahammülü olmayan durum SMS olur. Kullanıcıya hangi bildirimleri hangi kanaldan alacağını seçtiren bir tercih ekranı eklenir. Son olarak ticari içerik ile işlemsel bildirim ayrılır; sipariş bilgisi ile tanıtım mesajını aynı listeden göndermek, izin yönetimini imkânsızlaştırır.

Kısa kontrol listesi

• Olay adları tek bir listede tanımlı mı
• Alıcı kuralı ayarla mı belirleniyor, kodda sabit mi
• Şablonlar yetkili kullanıcı tarafından düzenlenebiliyor mu
• Gönderim kuyrukta ve arka planda mı yapılıyor
• Tekrar deneme sınırı ve başarısız kuyruğu var mı
• Aynı bildirimin iki kez gitmesini engelleyen tekil anahtar var mı
• Kalıcı hata dönen adresler işaretleniyor mu
• Kullanıcıya kanal tercihi sunuluyor mu
• İşlemsel ve ticari gönderimler ayrı mı

Özet: Bildirim altyapısı, olay-alıcı-kanal ayrımı, kuyruklu gönderim, şablon yönetimi ve teslim takibi olmak üzere dört sütun üzerinde durur. Bu dördü kurulduğunda yeni bir bildirim eklemek ayar işi, kurulmadığında her talep geliştirme işi olur. KAV Yazılım, özel yazılım projelerinde bildirim katmanını iş akışından ayrı bir bileşen olarak tasarlar.