Software Architecture

Mikroservislerde Mesaj Kuyruklarını Doğru Kullanmak: Temel Kavramlar ve Gerçek Dünya Yaklaşımları

Mikroservis mimarisine geçen ekiplerin yaşadığı problemlerin büyük kısmı, servislerin birbirinden ayrılmasından değil, servislerin birbirine nasıl bağlandığından kaynaklanıyor.
Mesaj kuyrukları (queues) bu yapının en kritik parçası olmasına rağmen çoğu projede doğru uygulanmadığı için sistem zamanla monolit davranmaya başlıyor.

Bu yazının ilk bölümünde, mikroservislerde sık geçen kavramları sade bir dille açıklıyoruz.
Ardından, gerçek dünyada sık sorulan sorular üzerinden sağlıklı bir queue mimarisi nasıl kurulmalı adım adım anlatıyoruz.

Temel Kavramlar: Önce Ne Nedir?

Aşağıda mikroservis mimarisini anlamanın temel bileşenlerini bulabilirsiniz.

1. Mikroservis Nedir?

Bir uygulamanın birbirinden bağımsız çalışan küçük servisler şeklinde tasarlanmasıdır.
Her servis kendi veritabanına ve deploy sürecine sahiptir.

Amaç: Kolay ölçeklenebilirlik, bağımsız geliştirme ve daha dayanıklı bir mimari.

2. Dağıtık Sistem Nedir?

Birden fazla servis veya bileşenin farklı yerlerde çalışmasına rağmen tek bir bütün gibi davranmasıdır.
Gerçek bir dağıtık sistem kurmak için mesajlaşma, hata toleransı ve servis izolasyonu doğru uygulanmalıdır.

3. Queue (Kuyruk) Nedir?

Servislerin birbirleriyle asenkron haberleşmesini sağlayan yapıdır.
Bir servis mesajı kuyruğa bırakır, başka bir servis mesajı hazır olduğunda tüketir.

4. Message Broker Nedir?

Mesajların doğru şekilde teslim edilmesini sağlayan altyapıdır.
Kafka ve RabbitMQ en yaygın kullanılan iki broker’dır.

5. Kafka Nedir?

Kafka, yüksek hacimli veri akışlarını işlemek için geliştirilmiş bir event streaming platformudur.
Mesajları diske yazar, silmez; tekrar okunmasını sağlar.

6. RabbitMQ Nedir?

RabbitMQ, iş akışlarında mesajları yönetmek için kullanılan geleneksel bir message broker’dır.
Mesajı alır, işler ve siler.

7. Event Nedir?

Sistemde gerçekleşen bir olayı temsil eden küçük veri paketidir.
Örnek: “Sipariş oluşturuldu.”

8. Consumer Nedir?

Kuyruktaki mesajı alıp işleyen servistir.

9. ACK Nedir?

Consumer’ın, mesajı başarıyla işlediğini broker’a bildirdiği onay bilgisidir.

10. Retry Nedir?

Hata durumunda mesajın yeniden işlenmesi sürecidir.

11. Idempotency Nedir?

Aynı mesajın birden fazla işlenmesi halinde tek bir sonuç üretmesini sağlayan yaklaşımdır.

12. DLQ (Dead Letter Queue) Nedir?

İşlenemeyen veya çok fazla başarısız işlem gören mesajların düştüğü güvenli kuyruğa verilen isimdir.

13. Partition Nedir?

Kafka’da paralel tüketimi sağlayan yapıdır. Her partition bağımsız bir akış gibi çalışır.

14. Routing Nedir?

RabbitMQ’da bir mesajın hangi kuyruğa gideceğini belirleyen kurallar bütünüdür.

Mikroservislerde Kuyruk Kullanımı: Doğru Yaklaşım Nasıl Olmalı?

Kavramları öğrendikten sonra artık mikroservislerde en çok sorulan konulara geçebiliriz.
Aşağıdaki başlıklar, gerçek projelerde sık karşılaşılan sorular ve doğru uygulama örnekleriyle hazırlanmıştır.

1. Kafka mı, RabbitMQ mu?

Bu iki teknoloji aynı amaçla üretilmiş gibi görünse de aslında farklı problemleri çözerler.

Kafka Ne Zaman Tercih Edilir?

Kafka, yüksek hacimli veri akışları ve bir olayın birden fazla servis tarafından tüketilmesi gereken durumlar için idealdir.

Örnek kullanımlar:

  • Log ve telemetri akışları

  • Clickstream analizi

  • Fraud ve ödeme süreçleri

  • Event sourcing mimarileri

Kafka bir message queue değil, dağıtık bir event log sistemidir.

RabbitMQ Ne Zaman Tercih Edilir?

RabbitMQ, iş akışlarının yönetildiği klasik senaryolarda daha uygundur.

Örnek kullanımlar:

  • Sipariş → stok → fatura süreci

  • Bildirim gönderimleri

  • Routing kuralları gerektiren yapılar

  • Düşük gecikme gerektiren işlemler

Kısaca:
Kafka = Veri akışı odaklı
RabbitMQ = İş akışı odaklı

2. Mesaj Kaybı Nasıl Engellenir?

Gerçek bir dağıtık mimaride mesaj kaybı kabul edilemez. Bunu sağlamak için dört temel ilke vardır:

Kalıcı Mesaj Saklama

Kafka doğal olarak diske yazar.
RabbitMQ’da kuyruğun durable, mesajların persistent olması gerekir.

Manual ACK

Consumer mesajı başarıyla tamamladığında ACK göndermelidir.
ACK yoksa mesaj tamamlanmış sayılmaz.

Idempotency

Aynı mesaj 1 veya 5 kez gelse bile sistem aynı işlemi yapmalıdır.

Dead Letter Queue

Hata veren mesajlar DLQ’ya düşer ve kontrol altına alınır.
DLQ olmayan sistemlerde hatalar sessizce kaybolur.

3. Sağlam Bir Queue Mimarisi Nasıl Kurulur?

Event-driven yaklaşım tercih edilmelidir.

Servisler arası bağımlılığı azaltır.
REST ile birbirine zincirlenen servisler zamanla monolite dönüşür.

Mesaj formatı standartlaştırılmalıdır.

JSON, Avro veya Protobuf gibi ortak bir format seçilmelidir.

Consumer’lar stateless olmalıdır.

State tutan consumer ölçeklenemez.
Stateless consumer her zaman daha hızlı çoğaltılabilir.

Tüm event’lerde correlation ID bulunmalıdır.

Dağıtık ortamda log takibi ve hata çözümü için kritik öneme sahiptir.

4. Yük Altında Consumer’lar Nasıl Ölçeklenir?

Kafka’da Ölçekleme

Kafka, partition sistemi sayesinde yüksek paralellik sağlar.
Partition sayısı = maksimum paralel tüketici sayısıdır.

RabbitMQ’da Ölçekleme

Aynı kuyruğa birden fazla consumer bağlanabilir.
Mesajlar tüm consumer’lara adil şekilde dağıtılır.
Kubernetes ortamında kuyruk uzunluğuna göre otomatik ölçeklendirme yapılabilir.

5. Retry, Idempotency ve DLQ Nasıl Doğru Tasarlanır?

Bu üç kavram dağıtık mimarinin en kritik noktalarıdır.

Retry

Her hata retry edilmez.
Ağ hataları ve geçici problemler retry edilmelidir.
İş mantığı hataları retry edilmez; DLQ’ya gönderilir.

Idempotency

Mesajın tekrar işlemesi sistemde ikinci bir etki yaratmamalıdır.
Bu genellikle eventId veya transactionId ile kontrol edilir.

DLQ

Başarısız mesajlar DLQ’ya düşer.
DLQ sayesinde:

  • Kaybolan veri riski ortadan kalkar

  • İnceleme ve tekrar oynatma (replay) mümkündür

Sonuç

Mikroservis geliştirmek tek başına yeterli değildir.
Gerçek bir dağıtık mimari oluşturmak için:

  • Mesajlaşma yapısı doğru kurulmalı

  • Servisler birbirine REST bağımlılığıyla bağlanmamalı

  • Retry, idempotency ve DLQ kurgusu sağlam olmalı

  • Consumer’lar stateless tasarlanmalı

  • Kafka ve RabbitMQ doğru senaryolarda kullanılmalı

Bu prensipler uygulanmadığında, sistem mikroservis görünümünde bir monolitte dönüşür.
Doğru uygulandığında ise esnek, dayanıklı ve ölçeklenebilir bir mimari ortaya çıkar.