Mimari ve Entegrasyon

Transactional Outbox Deseni: Veritabanı Kaydı ile Olay Yayınını Tutarlı Tutmak

InsureHub Ekibi
15 Ekim 2026

Olay tabanlı bir sistemde sık karşılaşılan bir senaryo düşünelim: Kullanıcı bir poliçeyi kaydeder. Uygulama önce poliçeyi veritabanına yazar, ardından "poliçe kaydedildi" olayını mesaj aracısına yayınlar. Bu olayı dinleyen bileşenler yenileme hatırlatmasını planlar, raporları günceller ve müşteriye bilgilendirme gönderir. Her şey yolunda gittiğinde bu akış kusursuz çalışır. Peki veritabanına yazma başarılı olduktan hemen sonra, olay yayınlanmadan önce sunucu kapanırsa ne olur?

Çift yazma sorunu

Yukarıdaki durumda poliçe veritabanında vardır ama hiçbir bileşen bundan haberdar değildir. Yenileme hatırlatması kurulmaz, raporlar eksik kalır. Sıralamayı tersine çevirmek de çözüm değildir: Önce olay yayınlanır, ardından veritabanı yazması başarısız olursa bileşenler var olmayan bir poliçe için işlem yapar. Bu soruna çift yazma sorunu denir. İki farklı sisteme, yani veritabanına ve mesaj aracısına, atomik olarak yazmak doğrudan mümkün değildir.

Dağıtık işlem protokolleri teorik bir çözüm sunar ama karmaşıktır, performansı düşürür ve birçok modern mesaj aracısı tarafından desteklenmez. Pratikte daha yaygın ve daha sağlam bir yöntem tercih edilir: Transactional outbox deseni.

Outbox deseninin özü

Desenin fikri basittir: Olayı doğrudan mesaj aracısına göndermek yerine, iş verisiyle aynı veritabanı içindeki özel bir tabloya yazın. Bu tabloya genellikle "outbox" yani giden kutusu denir. Poliçe kaydı ile outbox kaydı aynı veritabanı işleminin içinde yapılır. Veritabanı işlemleri atomik olduğu için ya ikisi birden yazılır ya da hiçbiri yazılmaz. Böylece çift yazma sorunu, tek bir sisteme yapılan tek bir atomik yazmaya indirgenir.

Ardından ayrı bir süreç, outbox tablosundaki yayınlanmamış kayıtları okur, mesaj aracısına gönderir ve başarılı olanları yayınlandı olarak işaretler. Bu süreç çökerse yeniden başladığında kaldığı yerden devam eder; çünkü hangi kayıtların henüz yayınlanmadığı veritabanında açıkça durmaktadır.

Outbox tablosunun yapısı

Tipik bir outbox kaydı şu alanları içerir:

  • Benzersiz olay kimliği: Tüketicilerin mükerrer olayları ayıklaması için gereklidir.
  • Toplam türü ve kimliği: Olayın hangi kayda ait olduğunu belirtir; örneğin poliçe ve poliçe kimliği.
  • Olay türü: "PoliçeKaydedildi", "KaskoTeklifiOluşturuldu" gibi.
  • Olay yükü: Olayın içeriği, genellikle JSON biçiminde.
  • Oluşturulma zamanı
  • Yayın durumu ve yayın zamanı
  • Acente kimliği: Çok kiracılı yapılarda olayın kapsamını belirler.

Yayınlayıcıyı çalıştırmanın iki yolu

Sorgulama tabanlı yayınlayıcı

Arka planda çalışan bir süreç, kısa aralıklarla outbox tablosunu sorgular, yayınlanmamış kayıtları sırayla alır ve gönderir. Uygulaması kolaydır ve ek altyapı gerektirmez. Dezavantajı, sorgulama aralığı kadar bir gecikme ve sürekli çalışan sorguların veritabanına bindirdiği yüktür. Küçük ve orta ölçekli sistemler için genellikle yeterlidir.

Birden fazla yayınlayıcı örneği çalışıyorsa aynı kaydın iki kez alınmasını önlemek için satır kilitleme veya kilitli satırları atlayan sorgu yöntemleri kullanılmalıdır.

Değişiklik veri yakalama

Değişiklik veri yakalama (Change Data Capture, CDC), veritabanının kendi değişiklik günlüğünü okuyarak tabloya eklenen yeni satırları anlık olarak yakalar. Outbox tablosuna yeni bir satır yazıldığı anda CDC aracı bunu fark eder ve mesaj aracısına iletir. Gecikme çok düşüktür ve veritabanına sorgulama yükü binmez. Ancak ek bir altyapı bileşeni kurmayı, yapılandırmayı ve izlemeyi gerektirir.

Tüketici tarafında sorumluluklar

Outbox deseni olayların kaybolmamasını garanti eder; ancak olayların tam olarak bir kez teslim edileceğini garanti etmez. Yayınlayıcı bir olayı gönderip yayınlandı olarak işaretleyemeden çökerse, yeniden başladığında aynı olayı tekrar gönderir. Bu nedenle tüketiciler idempotent olmalıdır. En yaygın yöntem, işlenen olay kimliklerini kaydetmek ve aynı kimlik tekrar geldiğinde işlemi atlamaktır.

Sıralama da dikkat gerektirir. Aynı poliçeye ait olayların sırasının korunması önemliyse, olaylar toplam kimliğine göre bölümlenerek aynı bölümde sırayla işlenmelidir.

Outbox tablosunun bakımı

Yayınlanmış kayıtlar outbox tablosunda süresiz birikirse tablo büyür ve yayınlayıcının sorguları yavaşlar. Yayınlanmış kayıtlar belirli bir süre sonra silinmeli veya arşiv tablosuna taşınmalıdır. Bu süre, hata ayıklama ve olası yeniden yayın ihtiyaçlarını karşılayacak kadar uzun, tabloyu şişirmeyecek kadar kısa olmalıdır. Olay yükünde kişisel veri varsa saklama süresi veri koruma politikalarıyla da uyumlu tutulmalıdır.

İzlenmesi gereken göstergeler

  1. Yayınlanmayı bekleyen kayıt sayısı
  2. En eski yayınlanmamış kaydın yaşı
  3. Yayın hatası oranı
  4. Olay oluşturma ile yayın arasındaki ortalama gecikme

Bekleyen kayıt sayısının sürekli artması, yayınlayıcının durduğuna veya mesaj aracısında bir sorun olduğuna işaret eder ve hızla müdahale edilmelidir.

Gelen kutusu: Desenin tüketici tarafındaki eşi

Outbox deseninin tüketici tarafındaki karşılığı "inbox" yani gelen kutusu desenidir. Tüketici, aldığı olayı işlemeden önce olay kimliğini kendi veritabanındaki gelen kutusu tablosuna yazar ve iş verisi değişikliğini aynı veritabanı işlemi içinde yapar. Olay daha önce işlendiyse benzersizlik kısıtı ikinci yazmayı engeller ve işlem atlanır. Böylece mükerrer teslimat, tüketicinin iş verisinde mükerrer etkiye dönüşmez. Outbox ve inbox birlikte kullanıldığında, en az bir kez teslimat garantisi pratikte tam olarak bir kez işleme etkisine yaklaşır.

Ne zaman outbox gerekmez?

Her olay için bu desen şart değildir. Kaybolması ciddi sonuç doğurmayan bildirimler, örneğin bir ekranın canlı güncellenmesi için gönderilen anlık sinyaller, doğrudan yayınlanabilir. Outbox, kaybolması iş açısından tutarsızlık yaratan olaylar için ayrılmalıdır: Poliçe kaydı, tahsilat, yenileme planlaması ve iptal gibi. Bu ayrım, altyapının gereksiz karmaşıklaşmasını önler.

Acente yazılımı açısından anlamı

Kullanıcı gözünden outbox deseni görünmezdir. Ancak etkisi açıktır: Kaydedilen her poliçenin yenileme hatırlatması kurulur, her tahsilat raporlara yansır ve hiçbir işlem arada kaybolmaz. InsureHub gibi sigorta acentelerine yazılım sağlayan bir platformda Acente CRM, poliçe takibi ve bildirim modülleri arasındaki tutarlılık bu tür desenlere dayanır. Böyle bir altyapının günlük kullanımda nasıl hissettirdiğini görmek isterseniz demo talebi oluşturabilir, sigorta acentesi yazılımı sayfasından genel yapıyı inceleyebilirsiniz.