> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/message-queue-nedir-rabbitmq-ve-kafka-ne-ise-yarar*

---

# Message Queue Nedir? RabbitMQ ve Kafka Ne İşe Yarar?

*Yayın Tarihi: 2026-11-12 04:00:01*

Bir kullanıcı rapor oluşturma düğmesine bastığında işlemin dakikalar sürmesi, web isteğinin açık tutulmasını gerektirmemelidir. Sipariş sonrasında e-posta gönderme, görsel işleme, webhook teslimi veya toplu veri aktarımı gibi görevler de kullanıcı yanıtından ayrılabilir. Message queue, işi üreten uygulama ile işi gerçekleştiren worker arasında tampon görevi görerek bu ayrımı sağlar.
Mesajlaşma altyapısının amacı yalnızca işlemi “arka plana atmak” değildir. Trafik dalgalanmalarını yumuşatmak, tüketicileri bağımsız ölçeklemek, geçici hatalarda yeniden denemek ve üretici ile tüketicinin aynı anda erişilebilir olma zorunluluğunu azaltmak da temel faydalardır. Buna karşılık tekrar teslim, mesaj sırası, poison message, kuyruk birikmesi ve veri tutarlılığı yeni sorumluluklar oluşturur.
Bu rehber, event-driven architecture düşünme modelini yeniden anlatmaz. Odak; mesaj kuyruğunun çalışma biçimi, producer–consumer ilişkisi, acknowledgment ve retry mekanizmaları ile RabbitMQ ve Kafka’nın hangi rollerde daha anlamlı olduğudur.

## Message queue nedir?

Message queue, bir uygulamanın ürettiği mesajları geçici veya kalıcı biçimde saklayan ve tüketicilerin daha sonra işlemesine izin veren mesajlaşma yapısıdır. Producer mesajı doğrudan hedef işlemin fonksiyonuna göndermek yerine bir broker veya kuyruk sistemine yayınlar. Consumer, uygun olduğunda mesajı alır, işlemi tamamlar ve çoğu sistemde başarı durumunu onaylar.
Microsoft Azure’un asenkron mesajlaşma rehberi, producer ile consumer arasına broker konularak iki tarafın zaman ve kapasite bakımından ayrılabildiğini açıklar  [Microsoft Asenkron Mesajlaşma Seçenekleri](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/messaging). Bu ayrım, kullanıcı isteğinin uzun süren işlerden etkilenmesini azaltabilir.
**Temel düşünce:** Producer işi hemen tamamlatmak zorunda değildir; işlenmesi gereken güvenli bir mesaj bırakır. Consumer mesajları kendi kapasitesine göre alır. Kuyruk, yoğun anlarda yükü yok etmez; yükü zamana yayarak sistemin kontrollü işlemesine yardımcı olur.

## Producer, broker, queue ve consumer ne anlama gelir?

Mesajlaşma sistemindeki roller birbirinden ayrıldığında mimari daha kolay anlaşılır. Producer, iş emrini veya olayı oluşturur. Broker, mesajı kabul eder, saklar ve yapılandırılan kurallara göre yönlendirir. Queue veya topic mesajların tutulduğu mantıksal kanaldır. Consumer ise mesajı alıp işleyen uygulama veya worker örneğidir.

- **Producer:** “Fatura oluştur”, “görseli işle” veya “sipariş oluşturuldu” mesajını yayınlayan uygulama.

- **Broker:** Mesaj kabulü, yönlendirme, saklama ve teslim süreçlerini yöneten altyapı.

- **Queue:** Mesajların tüketim için beklediği kanal.

- **Topic:** Bir olay akışını veya birden fazla abonelik modelini temsil eden mantıksal kanal.

- **Consumer:** Mesajı işleyen worker, servis veya uygulama örneği.

- **Consumer group:** İş yükünü paylaşan veya aynı akışı bağımsız biçimde takip eden tüketici grubu.

RabbitMQ’nun AMQP modelinde publisher mesajı bir exchange’e gönderir; exchange binding kurallarına göre mesajı sıfır veya daha fazla queue’ya yönlendirir. Consumer ise queue’dan mesaj alır  [RabbitMQ AMQP Modeli](https://www.rabbitmq.com/tutorials/amqp-concepts).

## Asenkron işleme neden kullanılır?

Senkron akışta kullanıcı isteği bütün alt işlemler tamamlanana kadar bekler. E-posta servisi yavaşsa sipariş yanıtı da gecikebilir. Asenkron yapıda sipariş kaydı tamamlandıktan sonra e-posta görevi kuyruğa bırakılır ve kullanıcıya yanıt dönülür. Worker mesajı daha sonra işler.
Bu yaklaşım, [iş süreci otomasyonu](/is-sureci-otomasyonu) projelerinde farklı görevleri birbirinden ayırabilir. Ancak kullanıcıya “işlem tamamlandı” denirken yalnızca mesaj kuyruğa yazılmışsa durum doğru ifade edilmelidir. “Talebiniz alındı” ile “rapor hazırlandı” aynı durum değildir.
Asenkron işlem, kritik iş kurallarının belirsiz hale getirilmesi anlamına gelmez. Hangi adımın kullanıcı yanıtından önce kesin tamamlanacağı, hangi adımın arka planda yürütüleceği ve başarısızlıkta kullanıcıya nasıl bilgi verileceği açıkça tanımlanmalıdır.

## Queue-based load leveling nasıl çalışır?

Trafik her zaman dengeli gelmez. Kampanya, toplu içe aktarma veya zamanlanmış görevler kısa sürede çok sayıda işlem üretebilir. Worker kapasitesi bu zirveye göre kurulursa normal zamanlarda kaynaklar boş kalır. Kuyruk, gelen işleri tamponlayarak worker’ların sürdürülebilir hızda işlemesine izin verir.
Microsoft’un Queue-Based Load Leveling modeli, queue’nun görev ile onu işleyen servis arasında tampon görevi görerek ani yüklerin etkisini azalttığını belirtir  [Microsoft Queue-Based Load Leveling](https://learn.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling). Kuyruk büyüyorsa sistem çalışıyor görünse bile iş gecikmesi artıyor olabilir; yalnızca hata oranını değil kuyruk yaşını da izlemek gerekir.

## Competing consumers ne sağlar?

Aynı queue’dan birden fazla worker mesaj tüketebilir. Her mesaj genellikle worker’lardan birine verilir ve iş yükü örnekler arasında paylaşılır. Trafik yükseldiğinde consumer sayısı artırılabilir; düştüğünde azaltılabilir. Azure’un Competing Consumers modeli, çoklu tüketicilerin queue’daki mesajları paralel işleyerek ölçekleme sağlamasını açıklar  [Microsoft Competing Consumers](https://learn.microsoft.com/en-us/azure/architecture/patterns/competing-consumers).
Paralellik arttığında mesaj sırası ve aynı kaynağa eş zamanlı erişim sorunları doğabilir. Aynı siparişe ait iki mesaj farklı worker’larda aynı anda çalışıyorsa uygulama seviyesinde sıralama, kilit veya idempotency gerekebilir.

## Acknowledgment neden önemlidir?

Broker mesajı consumer’a gönderdiğinde işin gerçekten tamamlandığını hemen bilemez. Manual acknowledgment kullanımında consumer işlemi başarıyla bitirdikten sonra broker’a onay gönderir. Consumer mesajı aldıktan sonra çökerse ve onay göndermediyse broker mesajı tekrar teslim edebilir.
RabbitMQ dokümantasyonu, otomatik acknowledgment modunun daha yüksek throughput sağlayabilse de bağlantı işleme tamamlanmadan kesilirse teslim güvenliğini azaltabileceğini; manual acknowledgment ve sınırlı prefetch kullanımının consumer yükünü kontrol etmeye yardımcı olduğunu açıklar  [RabbitMQ Consumer Acknowledgments](https://www.rabbitmq.com/docs/confirms).
Onay mesajı, iş sonucunun veritabanına güvenli biçimde kaydedilmesinden sonra gönderilmelidir. Önce acknowledgment gönderip sonra işlem yapmak, worker çökmesi halinde mesajın kaybolmasına neden olabilir.

## Prefetch ne işe yarar?

Prefetch, consumer’ın aynı anda kaç adet onaylanmamış mesaj alabileceğini sınırlar. Değer çok yüksekse worker işleyemeyeceği kadar mesajı belleğinde tutabilir ve diğer worker’lar boş kalabilir. Çok düşükse ağ gecikmesi nedeniyle throughput düşebilir.
RabbitMQ queue rehberi, manual acknowledgment ile prefetch sınırının outstanding teslimatları kontrol ettiğini belirtir  [RabbitMQ Queues](https://www.rabbitmq.com/docs/queues). Uygun değer mesaj işleme süresi, worker belleği ve paralellik seviyesine göre yük testiyle belirlenmelidir.

## Retry nasıl tasarlanmalıdır?

Geçici ağ hatası, dış servis zaman aşımı veya kısa süreli veritabanı problemi için yeniden deneme anlamlıdır. Şema hatası, eksik zorunlu alan veya kalıcı iş kuralı reddi ise aynı mesajın sınırsız tekrar denenmesiyle düzelmez. Hata türleri ayrılmalıdır.

- Geçici ve kalıcı hataları farklı sınıflandırın.

- Geçici hatalarda artan bekleme süresi ve jitter kullanın.

- Maksimum deneme sayısını belirleyin.

- Her denemeyi mesaj kimliğiyle izleyin.

- Consumer işlemini idempotent tasarlayın.

- Kalıcı başarısız mesajları inceleme alanına taşıyın.

- Manuel yeniden işleme için yetki ve audit kaydı oluşturun.

Retry hemen aynı queue’ya requeue edilirse bozuk mesaj çok hızlı döngüye girebilir. Gecikmeli retry queue’su, zamanlanmış teslim veya uygulama tarafından yönetilen bekleme mekanizması kullanılabilir.

## Dead-letter queue nedir?

Belirlenen deneme sayısını aşan, süresi dolan veya tüketici tarafından kalıcı olarak reddedilen mesajlar dead-letter queue veya ayrı bir dead-letter akışına taşınabilir. Amaç mesajı görünmez biçimde silmek değil, ana kuyruğun akışını engellemeden incelemek ve gerekirse düzeltip yeniden işlemektir.
RabbitMQ’da dead-letter edilen mesajlar yapılandırılmış bir dead-letter exchange’e yeniden yayınlanabilir. Resmî dokümantasyon, negative acknowledgment, mesaj TTL’si, queue uzunluk sınırı veya quorum queue delivery limitinin dead-lettering tetikleyicileri arasında olabileceğini belirtir  [RabbitMQ Dead Letter Exchanges](https://www.rabbitmq.com/docs/dlx).
Dead-letter alanı bir çöplük olmamalıdır. Mesaj sayısı, en eski mesaj yaşı, hata nedeni ve yeniden işleme sonucu izlenmelidir. Sürekli büyüyen DLQ, çözülmemiş üretim hatasının göstergesidir.

## Mesaj sırası garanti edilir mi?

“Queue FIFO’dur” ifadesi tek başına işleme sırasının her durumda korunacağını garanti etmez. Birden fazla consumer paralel çalışıyorsa ilk alınan mesaj daha geç tamamlanabilir. Retry edilen mesajlar sıranın arkasına veya farklı bir kuyruğa taşınabilir. Priority uygulaması da doğal sırayı değiştirebilir.
Mutlak sıra yalnızca gerçekten gerekli iş anahtarları için düşünülmelidir. Aynı sipariş veya müşteri kimliğine ait mesajlar aynı partition ya da sıralı kanal üzerinden işlenebilir. Bütün sistem için tek sıra oluşturmak throughput ve ölçeklemeyi ciddi biçimde sınırlar.

## At-least-once, at-most-once ve exactly-once ne anlama gelir?

Teslim yaklaşımıOlası sonuçUygulama sorumluluğu
At-most-onceMesaj en fazla bir kez işlenir; hata halinde kaybolabilirKayıp kabul edilebilir olmalıdır
At-least-onceMesaj kaybolmamak için tekrar teslim edilebilirConsumer idempotent olmalı ve tekrarları yönetmelidir
Exactly-onceBelirli sistem sınırları içinde sonuç bir kez görünür hale getirilmeye çalışılırBroker, producer, consumer ve dış veri kaynağının sınırları açıkça anlaşılmalıdır

İşletmeler için en güvenli varsayım, mesajın tekrar gelebileceğidir. Ödeme, fatura, stok veya webhook işleyicisi aynı mesajı ikinci kez aldığında çift işlem üretmemelidir. Exactly-once ifadesi ürün özelliği olarak görülse bile harici API ve veritabanı etkileri ayrıca değerlendirilmelidir.

## RabbitMQ nedir ve ne zaman kullanılır?

RabbitMQ, mesajları publisher’lardan alıp exchange ve binding kurallarına göre queue’lara yönlendiren bir message broker’dır. Direct, topic, fanout ve headers exchange tipleriyle görev dağıtımı ve routing senaryoları kurulabilir  [RabbitMQ AMQP Modeli](https://www.rabbitmq.com/tutorials/amqp-concepts).
RabbitMQ; iş kuyruğu, komut mesajı, farklı routing kuralları, kısa veya orta süre bekleyen görevler, consumer acknowledgment ve kontrollü retry gerektiren uygulamalarda güçlü bir seçenektir. E-posta gönderimi, dosya işleme, webhook teslimi, entegrasyon görevleri ve sipariş sonrası operasyonlar tipik örneklerdir.
Yüksek erişilebilirlik gereken yapılarda quorum queues, çoğaltılmış ve Raft tabanlı queue seçeneği sunar. RabbitMQ resmî dokümantasyonu quorum queue’ları veri güvenliği ve yüksek erişilebilirlik gereken çoğaltılmış queue’lar için modern seçenek olarak tanımlar  [RabbitMQ Quorum Queues](https://www.rabbitmq.com/docs/quorum-queues).

## Kafka nedir ve ne zaman kullanılır?

Apache Kafka, dağıtık event streaming platformudur. Producer kayıtları topic’lere yazar; topic’ler partition’lara bölünür ve consumer’lar offset bilgisiyle akışı okur. Kafka’nın resmî giriş dokümantasyonu, olayların topic içinde belirlenen retention süresi boyunca tutulabildiğini ve tüketildikten sonra otomatik olarak silinmek zorunda olmadığını belirtir  [Apache Kafka Introduction](https://kafka.apache.org/documentation/).
Bu yapı, aynı olay akışının farklı consumer group’lar tarafından bağımsız okunmasını ve gerektiğinde geçmiş kayıtların tekrar işlenmesini sağlar. Veri hattı, clickstream, log, değişiklik akışı, analitik besleme ve yüksek hacimli domain event dağıtımı Kafka’nın doğal kullanım alanlarıdır.
Kafka’da sıra partition içinde korunur. Aynı iş anahtarına ait kayıtların aynı partition’a yönlendirilmesi, o anahtar için sıralı tüketim sağlamaya yardımcı olur. Partition sayısı paralellik ve ölçek kararının parçasıdır.

## RabbitMQ ve Kafka arasındaki temel farklar

KriterRabbitMQKafka
Temel modelBroker, exchange, queue ve consumer odaklı mesajlaşmaPartition’lı, kalıcı ve yeniden okunabilir event log
Tipik işGörev dağıtımı, komut, routing, retry ve iş kuyruğuEvent streaming, veri hattı, analitik ve çoklu bağımsız tüketim
Tüketim sonrası mesajOnay sonrası queue’dan kaldırılması yaygındırRetention süresi boyunca topic’te kalabilir
YönlendirmeExchange ve binding ile esnek routingTopic ve partition anahtarı üzerinden dağıtım
Tekrar okumaStandart queue modelinde ana amaç değildirOffset geri alınarak geçmiş kayıtlar yeniden okunabilir
SıralamaQueue, consumer sayısı ve retry davranışına bağlıdırPartition içinde sıra korunur
Operasyon odağıQueue derinliği, unacked mesaj, consumer kapasitesiPartition, consumer lag, retention ve disk kapasitesi

Bu tablo bir performans kazananı ilan etmez. Aynı şirket içinde görev kuyruğu için RabbitMQ, veri akışı için Kafka kullanılabilir. Seçim, [API entegrasyonu](/api-entegrasyon-hizmeti) ve iş süreçlerinin mesaj tipine göre yapılmalıdır.

## RabbitMQ ne zaman daha uygun olabilir?

- Bir işin consumer’lardan yalnızca biri tarafından gerçekleştirilmesi gerekiyorsa.

- Exchange ve binding ile esnek routing isteniyorsa.

- Per-message acknowledgment, requeue ve dead-letter akışı temel ihtiyaçsa.

- Kısa ömürlü görevler ve arka plan worker sistemi kuruluyorsa.

- Consumer prefetch ve queue bazlı backpressure kontrolü önemliyse.

- Mesaj tüketildikten sonra uzun süre yeniden okunması gerekmiyorsa.

## Kafka ne zaman daha uygun olabilir?

- Aynı olay akışını birden fazla bağımsız ekip veya sistem okuyacaksa.

- Geçmiş olayların retention süresince yeniden işlenmesi gerekiyorsa.

- Yüksek hacimli event stream ve veri hattı kuruluyorsa.

- Partition anahtarıyla belirli kayıt gruplarında sıra korunacaksa.

- Consumer lag üzerinden akış gerisinde kalma ölçülecekse.

- Streaming analiz ve sürekli veri dönüşümü yapılacaksa.

## İkisini birlikte kullanmak doğru olabilir mi?

Evet. Sipariş sistemindeki domain event’leri Kafka’da tutulurken e-posta veya görsel işleme gibi tek tüketicili görevler RabbitMQ queue’larına yazılabilir. Kafka consumer’ı bir olayı okuyup belirli görev mesajlarını RabbitMQ’ya dönüştürebilir.
Bu hibrit yapı yalnızca açık gerekçe varsa kurulmalıdır. İki sistem; iki ayrı izleme, güvenlik, kapasite, yedekleme ve olay müdahalesi yükü getirir. Küçük bir projede yalnızca teknik çeşitlilik için iki broker kullanmak gereksiz karmaşıklık oluşturur.

## Message queue ne zaman gereksizdir?

İşlem kısa, güvenilir ve kullanıcı yanıtı için zorunluysa doğrudan senkron çağrı daha anlaşılır olabilir. Tek uygulama içinde basit bir fonksiyon çağrısını broker üzerinden geçirmek hata ayıklamayı zorlaştırabilir. Düşük trafikli projelerde veritabanı tabanlı kontrollü job tablosu da yeterli olabilir.
Queue kullanımı, iş sonucunun hemen bilinmesi gereken akışlarda sahte bir başarı yanıtı üretmemelidir. Sistemin asenkron başarısızlıkları kullanıcıya veya operatöre iletemediği durumlarda kuyruk yalnızca hatayı geciktirir.

## En sık yapılan mesaj kuyruğu hataları

- Mesajın yalnızca bir kez geleceğini varsaymak.

- Consumer işlemlerini idempotent tasarlamamak.

- Başarısız mesajları sınırsız requeue döngüsüne sokmak.

- Queue derinliğini izleyip en eski mesaj yaşını izlememek.

- Büyük dosya veya gereksiz payload’ı mesaj içine koymak.

- Şema sürümünü ve geriye uyumluluğu planlamamak.

- Bütün mesajlar için global sıra talep ederek paralelliği yok etmek.

- Broker erişilemediğinde producer davranışını belirlememek.

- RabbitMQ veya Kafka’yı kullanım modeli yerine popülerliğe göre seçmek.

## Uygulama öncesi kontrol listesi

- Mesaj bir komut mu, görev mi, yoksa yeniden okunabilir olay mı?

- İş kullanıcı yanıtından sonra tamamlanabilir mi?

- Mesaj tekrar geldiğinde çift sonuç oluşuyor mu?

- Ordering gerçekten hangi anahtar veya kapsam için gerekli?

- Retry edilebilir ve kalıcı hatalar ayrıldı mı?

- Dead-letter mesajları kim inceleyecek?

- Queue depth, message age, unacked count veya consumer lag izlenecek mi?

- Broker kesintisinde producer mesajı nasıl koruyacak?

- Payload boyutu ve hassas veri sınırları belirlendi mi?

- RabbitMQ, Kafka veya daha basit bir iş kuyruğu seçimi gerekçelendirildi mi?

## Sonuç: Mesaj tipi doğru aracı belirler

Message queue, producer ile consumer’ı zaman ve kapasite bakımından ayırarak uzun süren işleri arka plana taşır, ani yükleri tamponlar ve worker’ların bağımsız ölçeklenmesini sağlar. Bu faydalar; acknowledgment, retry, idempotency, ordering ve dead-letter yönetimi doğru kurulduğunda gerçek değere dönüşür.
RabbitMQ çoğunlukla görev dağıtımı, esnek routing ve queue odaklı işleme için güçlüdür. Kafka ise olayların belirli süre saklandığı, farklı consumer grupları tarafından yeniden okunabildiği ve yüksek hacimli akışların işlendiği sistemlerde öne çıkar. Doğru soru “hangisi daha iyi?” değil, “mesajın yaşam döngüsü ve tüketim modeli hangisini gerektiriyor?” olmalıdır.

### Asenkron iş akışınızı doğru mesajlaşma modeliyle kurun
Arka plan görevleri, entegrasyonlar ve olay akışları için RabbitMQ, Kafka veya daha yalın bir çözümün rollerini geliştirme öncesinde netleştirebilirsiniz.[Projenizi Webioo ile değerlendirin](/iletisim)

## Sıkça Sorulan Sorular

### Message queue kullanmak işlemin kesin tamamlanacağını garanti eder mi?

Hayır. Queue mesajın güvenli biçimde beklemesine ve tekrar teslim edilmesine yardımcı olabilir; fakat consumer hataları, broker ayarları ve dış servis sorunları ayrıca yönetilmelidir. İş sonucunun güvenilirliği acknowledgment, retry, idempotency ve izleme tasarımına bağlıdır.

### RabbitMQ ile Kafka aynı işi mi yapar?

Kısmen örtüşen mesajlaşma yetenekleri vardır; ancak temel modelleri farklıdır. RabbitMQ queue, routing ve görev dağıtımına; Kafka ise partition’lı, kalıcı ve yeniden okunabilir olay akışlarına daha doğal biçimde uyum sağlar.

### Mesaj kuyruğunda FIFO sırası her zaman korunur mu?

Hayır. Birden fazla consumer, retry, priority veya paralel işlem tamamlanma sırasını değiştirebilir. Sıra yalnızca gerekli iş anahtarı için tasarlanmalı; Kafka’da partition, RabbitMQ’da queue ve consumer düzeni buna göre planlanmalıdır.

### Consumer aynı mesajı iki kez alabilir mi?

Evet. At-least-once teslim modellerinde consumer mesajı işledikten sonra acknowledgment gönderemeden çökerse mesaj yeniden teslim edilebilir. Bu nedenle ödeme, fatura, stok ve webhook işleyicileri idempotent olmalıdır.

### Dead-letter queue’daki mesajlar otomatik olarak düzelir mi?

Hayır. Dead-letter alanı başarısız mesajları ana akıştan ayırır. Hata nedeni incelenmeli, veri veya kod sorunu düzeltilmeli ve mesaj kontrollü biçimde yeniden işlenmelidir. DLQ büyümesi için alarm kurulmalıdır.

### Küçük bir projede Kafka kullanmak gerekir mi?

Genellikle yalnızca yüksek hacimli akış, geçmiş olayları yeniden okuma veya çok sayıda bağımsız consumer gibi somut ihtiyaçlar varsa anlamlıdır. Basit arka plan işleri için RabbitMQ, yönetilen queue hizmeti veya daha yalın job sistemi yeterli olabilir.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/message-queue-nedir-rabbitmq-ve-kafka-ne-ise-yarar