Kafka mı RabbitMQ mu?

Bu soru genellikle throughput tablolarıyla cevaplanmaya çalışılıyor.

Bence önce farklı bir soru sormak gerekiyor:

Gönderdiğimiz şey bir iş mi, yoksa geçmişte gerçekleşmiş bir olay mı?

İş yapılacaksa

Bir PDF üretilecek olsun.

GenerateMonthlyReport

Bir worker mesajı alacak, raporu oluşturacak ve iş tamamlanacak.

Başarısızsa retry yapılacak.

Belirli sayıda denemeden sonra dead-letter akışına alınabilir.

Bu model doğal olarak queue modeline yakındır.

RabbitMQ’nun work queue, routing, acknowledgement ve publisher confirm mekanizmaları bu tür senaryolara doğrudan karşılık verir. RabbitMQ dokümantasyonu acknowledgements ve publisher confirms mekanizmalarının güvenilir teslimat açısından temel rolünü özellikle vurguluyor.

Olay kaydı tutulacaksa

Şimdi başka bir mesaj düşünelim:

PaymentCompleted

Bu event’i bugün notification sistemi tüketiyor olabilir.

Yarın fraud analytics eklenebilir.

Bir ay sonra reporting servisi geçmiş event’leri yeniden okumak isteyebilir.

Burada event işlendikten sonra değersiz hale gelmez.

Geçmişin parçasıdır.

Kafka’nın modeli tam olarak buna uygundur. Event’ler topic partition’larında retention süresi boyunca kalır ve farklı consumer grupları aynı event akışını bağımsız olarak okuyabilir.

Aynı sistemde ikisi birden olabilir

Burada sık yapılan hata teknoloji seçimini organizasyon standardına çevirmektir.

Biz Kafka kullanıyoruz, her şeyi Kafka’ya atalım.

veya:

RabbitMQ zaten var, event’leri de oradan geçirelim.

Oysa bir sistemde hem command/job hem domain event olabilir.

Örneğin:

PaymentCompleted → Kafka

GenerateInvoicePdf → RabbitMQ
SendEmail         → RabbitMQ

gayet mantıklı bir mimari olabilir.

Tek broker kullanmak operasyonu sadeleştirebilir; fakat bütün mesajların aynı semantiğe sahip olduğunu varsaymak başka bir problemdir.

Exactly-once beklentisi

Messaging tasarımında tehlikeli beklentilerden biri de “mesaj yalnızca bir kez gelir” varsayımıdır.

Network failure, acknowledgement kaybı veya consumer restart gibi durumlar duplicate processing üretebilir.

RabbitMQ dokümantasyonu da acknowledgement kullanılan modellerde yeniden teslimat yaşanabileceğini ve consumer tarafının duplicate handling/idempotency düşünmesi gerektiğini açıklıyor.

Bu nedenle consumer’ın:

event_id = evt_92831

gibi benzersiz bir identifier üzerinden daha önce işlenmiş event’leri tanıyabilmesi önemlidir.

Message broker seçimi ürün kataloğundan teknoloji seçmek değildir.

Önce mesajın semantiğini tanımlayın.

Sonra broker’ı seçin.

Tersi yapılırsa mimariyi teknoloji belirlemeye başlar.