Kuyruk tabanlı bir entegrasyon altyapısında mesajların büyük çoğunluğu sorunsuz işlenir. Ancak bazı mesajlar ne kadar denenirse denensin başarıya ulaşmaz: Beklenmeyen bir veri formatı, karşı tarafta kalıcı olarak kapatılmış bir uç nokta veya yazılımdaki bir hata bu mesajları sürekli geri çevirir. Bu mesajlar ana kuyrukta kalırsa diğer işleri tıkar; silinirse iz bırakmadan kaybolur. Ölü mektup kuyruğu (Dead Letter Queue, kısaca DLQ) bu iki kötü seçenek arasında üçüncü bir yol sunar.
Ölü mektup kuyruğu nedir?
DLQ, belirli koşulları sağlayan başarısız mesajların ana kuyruktan çıkarılıp taşındığı ayrı bir kuyruktur. Mesaj burada işlenmez; incelenmeyi bekler. Bu sayede ana kuyruk akmaya devam eder, sorunlu mesaj ise kaybolmadan saklanır. Kavram adını posta sistemlerinden alır: Adresi bulunamayan mektuplar imha edilmez, ayrı bir birimde bekletilir.
Bir mesaj ne zaman DLQ'ya gitmeli?
Her başarısızlık DLQ'ya gitmeyi hak etmez. Geçici hatalar için yeniden deneme mekanizması vardır. DLQ, yeniden denemenin anlamını yitirdiği durumlar içindir. Tipik koşullar şöyledir:
- Deneme sayısı aşıldı: Mesaj belirlenen azami deneme sayısına ulaştı ve hâlâ başarısız.
- Kalıcı hata alındı: Karşı servis, isteğin biçimsel olarak geçersiz olduğunu veya yetki bulunmadığını açıkça bildirdi. Bu tür hatalar tekrar denemekle düzelmez.
- Mesaj çözümlenemedi: Mesajın kendisi bozuk veya beklenen şemaya uymuyor.
- İş kuralı ihlali: Örneğin DASK sorgusu için zorunlu olan adres kodu eksik ve bu eksiklik otomatik olarak tamamlanamıyor.
Bu ayrımın net olması önemlidir. Geçici bir ağ sorunu yüzünden DLQ'ya düşen mesajlar, kuyruğu gereksiz yere kalabalıklaştırır ve gerçek sorunları gölgeler.
DLQ'ya taşınan mesaja eklenmesi gerekenler
DLQ'daki bir mesaj, inceleyen kişiye hikâyesini anlatabilmelidir. Yalnızca orijinal mesajı saklamak yetmez; aşağıdaki bağlam bilgileri de eklenmelidir:
- Mesajın ilk oluşturulma zamanı ve DLQ'ya düşme zamanı
- Toplam deneme sayısı
- Son alınan hata kodu ve hata mesajı
- Mesajı işleyen bileşenin adı ve sürümü
- İlgili acente, branş ve hedef şirket bilgisi
- Uçtan uca takip için korelasyon kimliği
Bu bilgiler sayesinde inceleme, loglar arasında saatlerce arama yapmadan doğrudan doğru yere odaklanabilir.
DLQ'yu yönetmek için bir çalışma düzeni
DLQ kurmak kolaydır; zor olan onu düzenli yönetmektir. Bakılmayan bir DLQ, kimsenin açmadığı bir çekmeceye dönüşür. Sağlıklı bir yönetim için şu döngü önerilir:
1. Bildirim
DLQ'ya her mesaj düştüğünde değil, belirli bir eşik aşıldığında veya belirli bir şirket ve branş için yoğunlaşma görüldüğünde operasyon ekibine uyarı gitmelidir. Tek tek her mesaj için bildirim, kısa sürede görmezden gelinen bir gürültüye dönüşür.
2. Sınıflandırma
Mesajlar hata türüne göre gruplanır. Aynı hata mesajıyla düşmüş yüz mesaj, genellikle tek bir kök nedene işaret eder. Gruplama, ekibin yüz ayrı sorunla değil tek bir sorunla uğraştığını görmesini sağlar.
3. Kök neden düzeltmesi
Sorun yazılımdaysa düzeltme yapılır ve yayınlanır. Sorun karşı servisteyse ilgili tarafla iletişime geçilir. Sorun veri kaynaklıysa kullanıcıya hangi alanın düzeltilmesi gerektiği bildirilir.
4. Yeniden işleme
Kök neden giderildikten sonra mesajlar kontrollü biçimde ana kuyruğa geri gönderilir. Bu işlem bir anda yapılmamalı, kademeli olarak ve sonuçlar izlenerek ilerlemelidir.
5. Arşiv veya silme
Yeniden işlenmesi anlamsız olan mesajlar, örneğin müşterinin çoktan vazgeçtiği bir teklif sorgusu, belirlenen saklama politikasına göre arşivlenir veya silinir. Kişisel veri içeren mesajların süresiz saklanmaması, veri koruma yükümlülükleri açısından da önemlidir.
Yeniden işleme sırasında dikkat edilmesi gerekenler
DLQ'dan mesajları geri göndermek masum bir işlem gibi görünür ama bazı riskler taşır. En önemlisi zamanlamadır. Teklif sorguları zamana duyarlıdır; günler önce başlatılmış bir kasko sorgusunu bugün yeniden işlemek, kullanıcının artık beklemediği bir sonucu ekrana getirebilir. Bu nedenle yeniden işleme öncesinde mesajın hâlâ anlamlı olup olmadığı kontrol edilmelidir.
İkinci risk mükerrer işlemdir. Mesaj DLQ'ya düşmeden önce kısmen başarılı olmuş olabilir. İşleyicilerin idempotent tasarlanmış olması, yani aynı mesajın ikinci kez işlenmesinin yan etki üretmemesi, güvenli yeniden işlemenin ön koşuludur.
Üçüncü risk ise toplu yeniden işlemenin karşı servise ani yük bindirmesidir. Yüzlerce mesajı bir anda geri göndermek, az önce toparlanan bir şirket servisini yeniden zorlayabilir. Yeniden işleme hızını sınırlamak bu riski azaltır.
DLQ'yu ölçmek: Hangi göstergeler anlamlı?
DLQ'nun sağlığı birkaç basit göstergeyle izlenebilir. Birincisi kuyruktaki toplam mesaj sayısı ve bu sayının zaman içindeki eğilimidir; sürekli artan bir DLQ, çözülmemiş bir kök nedene işaret eder. İkincisi en eski mesajın yaşıdır; günlerdir bekleyen mesajlar, kimsenin DLQ'ya bakmadığını gösterir. Üçüncüsü hata türlerinin dağılımıdır; tek bir şirket veya tek bir branşta yoğunlaşma, sorunu hızla daraltır. Son olarak yeniden işlenen mesajların başarı oranı izlenmelidir. Geri gönderilen mesajlar yeniden DLQ'ya düşüyorsa kök neden henüz giderilmemiştir.
Bu göstergeler, entegrasyon katmanının genel sağlık panelinde ayrı bir bölüm olarak yer almalıdır. Böylece DLQ teknik ekibin unuttuğu bir köşe değil, düzenli gözden geçirilen bir operasyon alanı haline gelir.
Kullanıcı tarafında şeffaflık
DLQ teknik bir kavramdır ama sonuçları kullanıcıya dokunur. DLQ'ya düşen bir teklif sorgusu, kullanıcının ekranında sonsuza kadar "bekleniyor" olarak kalmamalıdır. Bunun yerine sorgunun tamamlanamadığı, mümkünse nedeniyle birlikte gösterilmelidir. Kullanıcı eksik bir bilgiyi tamamlayarak sorguyu yeniden başlatabilir ya da diğer şirketlerin sonuçlarıyla çalışmaya devam edebilir.
InsureHub'da başarısız mesajların yönetimi
Sigorta acentelerine yazılım sağlayan InsureHub açısından DLQ, entegrasyon katmanının sessiz hata biriktirmesini önleyen bir güvenlik ağıdır. Sigorta teklif programı içinde tamamlanamayan bir sorgunun kaybolmaması, operasyon ekibinin bunu görebilmesi ve sigorta acentesi yazılımı kullanıcısının durumdan haberdar olması bu yapının hedefleridir.
Kendi altyapınızı değerlendirirken şu soruyla başlayabilirsiniz: Geçen hafta başarısız olan entegrasyon mesajlarının listesini, hata türlerine göre gruplanmış halde birkaç dakika içinde görebiliyor musunuz? Görebiliyorsanız DLQ'nuz işini yapıyordur.