1. GİRİŞ

Modern dağıtık uygulamalar, mikroservisler ve gerçek zamanlı işlemler arttıkça sistemler arasında güvenilir, asenkron iletişim kurma ihtiyacı da büyüdü. Mesajlaşma sistemleri (messaging systems) bu ihtiyacı karşılamak için kullanılan temel altyapılardır. Sadece verinin taşınması değil; kuyruklama, teslim garantileri, ordering, backpressure ve event sourcing gibi kavramlar da mesajlaşma katmanında çözülür. Bu nedenle doğru mesajlaşma mimarisi seçimi uygulama performansı, veri tutarlılığı ve operasyon maliyeti üzerinde doğrudan etki yapar.

Bu konu neden bugün önemli?

• Cloud‑native uygulamalar ve mikroservis tabanlı entegrasyonlar artıyor.
• Gerçek zamanlı analitik, event‑driven mimariler ve serverless fonksiyonlar mesaj tabanlı iletişimle ölçekleniyor.
• Yüksek erişilebilirlik, dayanıklılık ve backpressure yönetimi için asenkron iletişim gerekli.

Kimler için önemli?

• Yazılım mimarları ve backend mühendisleri
• Platform mühendisleri, SRE ve DevOps ekipleri
• Data mühendisleri ve gerçek‑zamanlı analitik ekipleri

Hangi problemleri çözüyor?

• Servisler arası zaman bağımsız iletişim (decoupling)
• Peaks yönetimi ve traffic smoothing (kuyruklama, backpressure)
• Garanti edilen teslim (at‑least‑once, at‑most‑once, exactly‑once) ve ordering

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar ve terminoloji

• Producer: Mesaj üreten taraf.
• Consumer: Mesajı işleyen taraf.
• Broker: Mesajları kabul eden, saklayan ve dağıtan altyapı (Kafka, RabbitMQ, Pulsar, AWS SQS).
• Queue: Mesajların sıralı olarak tutulduğu yapı; genelde point‑to‑point.
• Topic / Pub‑Sub: Birden fazla consumer'ın aynı mesajı alabileceği yayınlama/abonelik modeli.
• Offset/Cursor: Mesaj konumunu takip eden pointer.
• Delivery Semantics: at‑most‑once, at‑least‑once, exactly‑once.

2.2 Queue vs Pub/Sub

Queue (kuyruk) tek bir tüketicinin mesajları alması için uygundur; işler dağıtılarak paralelleştirilebilir. Pub/Sub (topic) modeli aynı mesajın birden fazla abonelere dağıtılması gerektiğinde tercih edilir. Bu iki model birbirine dönüştürülebilir veya birlikte kullanılabilir; tasarım ihtiyaca göre seçilir.

2.3 Delivery semantics — ne anlama gelir?

• At‑most‑once: Mesaj en fazla bir kez teslim edilir — loss mümkündür, duplicate yoktur.
• At‑least‑once: Mesaj en az bir kez teslim edilir — duplicate olabilir, idempotency gerekir.
• Exactly‑once: Her mesaj tam bir kez işlenir — genelde kompleks mekanizmalar gerektirir ve maliyetlidir.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE AKIŞ

3.1 Broker tabanlı mimari

Broker yaklaşımlarında üreticiler mesajı broker'a gönderir; broker mesajı kalıcı depolama veya hafıza içi yapıda tutar ve alıcı taleplerine göre dağıtır. Broker, replication, persistence, ordering, partitioning gibi karmaşık görevleri üstlenir. Brokerless yaklaşımlar (örn. bazı peer‑to‑peer) ise uygulama düzeyinde mesaj taşıma sorumluluğunu paylaşır; genelde ölçeklenebilirlik ve yönetim açısından broker tabanlı çözümler daha pratiktir.

3.2 Partitioning ve paralel tüketim

Yüksek throughput için mesajların partition'lara dağıtılması ve partition başına bir tüketici grubu atanması yaygındır. Bu, ordering garantilerini partition sınırına kadar kısıtlar. Partition key tasarımı (hangi alan üzerinden partition yapılacağı) performans ve hot‑key problemlerini doğrudan etkiler.

3.3 Offset yönetimi ve checkpointing

Consumer'lar mesaj pozisyonlarını (offset) saklayarak hangi mesajları işlediğini takip eder. Stream processing sistemlerinde checkpointing (ör. Kafka Streams, Flink) uygulama state'i ile offset'i eş zamanlı commit ederek fault‑tolerant processing sağlar.

3.4 Retention ve compaction

Broker'lar mesaj saklama stratejisi (retention) sunar: süre bazlı veya boyut bazlı. Bazı sistemler (Kafka) log compaction ile key‑based son değeri saklayarak state store gibi davranır; bu pattern event sourcing ile uyumludur.

3.5 Backpressure ve flow control

Tüketiciler yavaşsa producer'lar üzerindeki baskıyı yönetmek gerekir. Backpressure mekanizmaları (consumer pull, rate limiting, throttling, buffering) sistem kararlılığını sağlar. Reactive programlama kütüphaneleri bu konuda model sunar (Reactive Streams, Akka Streams).

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Apache Kafka — yüksek throughput, stream platform

Kafka, dağıtık commit log tabanlı bir mesajlaşma sistemidir. Ölçeklenebilir partitioning, retention, replication ve stream processing ekosistemi (Kafka Streams, ksqlDB) ile gerçek zamanlı pipeline'lar için tercih edilir. Kafka genelde event sourcing, change data capture (CDC) ve analytics için kullanılır.

4.2 RabbitMQ — message broker & routing

RabbitMQ AMQP protokolünü uygular ve zengin routing (exchange türleri), per‑message TTL, dead‑letter, ack/nack gibi özelliklerle klasik mesajlaşma senaryolarında güçlüdür. Queue yönelimli kullanım, RPC tarzı işlemler ve küçük/orta ölçekli işler için uygundur.

4.3 Apache Pulsar — multi‑tenant, geo‑replication

Pulsar, ayrıştırılmış storage (BookKeeper) ve broker mimarisi ile ölçeklenebilirliği hedefler. Multi‑tenant özellikleri, tiered storage ve geo‑replication yetenekleri Pulsar'ı büyük ölçekli dağıtık sistemler için çekici kılar.

4.4 Bulut servisleri — SQS, SNS, Event Hubs, Pub/Sub

AWS SQS/SNS, Azure Service Bus/Event Hubs, Google Pub/Sub gibi managed çözümler operasyonel yükü azaltır. Her servisin API ve özellik seti farklıdır: SQS queue odaklıyken SNS publish/subscribe modelini sunar; Event Hubs ve Pub/Sub yüksek throughput stream senaryolarına odaklanır.

4.5 Use cases

• Order processing — asenkron faturalama, fulfillment ve bildirim hattı
• Eventsourcing & CQRS — write model event olarak loglanır, read model rehydrate edilir
• Real‑time analytics — kullanıcı davranışı, metrikler ve fraud detection
• Integration & ETL pipelines — farklı sistemler arasında veri taşıma

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Loose coupling — servisleri zaman açısından birbirinden bağımsızlaştırır
• Scale ve resilience — kuyruklama ile burst'leri yumuşatma
• Farklı tüketiciler için aynı olayın yeniden kullanılabilirliği (pub/sub)

Sınırlamalar

• Operasyonel karmaşıklık — broker yönetimi, storage, replication ve tuning
• Ordering garanti zorlukları — partition bazlı ordering veya global ordering karmaşası
• Data retention maliyeti — uzun süreli retention storage ücreti

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Mesaj boyutlarını sınırlandırın; büyük payload'ları object store'da tutup referans gönderin.
• Partition key stratejisini veri erişim kalıplarına göre tasarlayın; hot key'leri tespit edin ve çözün.
• Retention ve compaction politikalarını iş gereksinimlerine göre planlayın.

Performans optimizasyonu

• Pipelining ve batch tüketim ile throughput'u artırın; küçük ACK gecikmeleri toplam performansı etkiler.
• Broker konfigürasyonunu I/O, disk, network parametrelerine göre tune edin (replication factor, replication lag).

Güvenlik

• Encryption in transit (TLS) ve at rest, authentication/authorization (SASL, IAM) uygulayın.
• Least privilege ile topic/queue erişimini sınırlayın; audit logging aktif edin.

Observability

• Lag, consumer offset, throughput, consumer group health, broker disk usage ve JVM/OS metriklerini izleyin.
• Alert'leri SLA'lara göre tanımlayın: consumer lag p99, broker under‑replication vb.

8. SIK YAPILAN HATALAR

• Mesaj boyutunu büyük tutmak — broker I/O ve network'i zorlar.
• Idempotency ihmal etmek — at‑least‑once ile duplicate'lar problem yaratır.
• Offset commit'lerini yanlış yönetmek — data loss veya duplicate processing oluşabilir.
• Hot partition problemi — key seçimi ile tek partition'a aşırı yük binmesi.

9. GELECEK TRENDLER

1. Serverless event buses: Managed, ölçeklenebilir ve düşük operasyonlu event platformları daha fazla benimseniyor.
2. Edge event processing: Olayların bir kısmının edge'de işlenmesi (filtering, enrichment) gecikmeyi düşürecek.
3. Exactly‑once in practice: Distributed transactions, idempotency idari ve teknik araçlarla daha erişilebilir hale gelecek.
4. AI‑assisted routing & optimization: Telemetry verisine göre dinamik partitioning, retention ve routing kararları otomatikleştirilecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Hangi mesajlaşma sistemini seçmeliyim?

   Seçim ihtiyaçlara bağlıdır: yüksek throughput ve stream processing için Kafka; zengin routing ve klasik broker gereksinimleri için RabbitMQ; multi‑tenant ve geo‑replication için Pulsar veya managed cloud çözümleri tercih edilebilir.

2. 2. At‑least‑once ile nasıl güvenli çalışırım?

   Consumer tarafında idempotent işlemler uygulayın; message deduplication, idempotency keys veya dedupe store kullanın.

3. 3. Mesaj boyutu sınırı ne olmalı?

   Genelde broker'lar 1–10 MB sınırı uygular. Büyük veriyi object store'a koyup mesajda referans göndermek en sağlıklısıdır.

4. 4. Ordering garantisi nasıl sağlanır?

   Partition key kullanarak per‑key ordering sağlarsınız; global ordering gerekiyorsa ek koordinasyon veya single partition gerekebilir fakat performans maliyeti yüksektir.

5. 5. Consumer lag nedir ve neden kritik?

   Consumer lag, tüketicinin son commit ettiği offset ile en son üretilen offset arasındaki farktır. Yüksek lag gerçek zamanlılığı bozar ve backlog birikimi riskine işaret eder.

6. 6. Mesajlaşma sistemlerinde testing önerileri nelerdir?

   Integration test, fault injection (broker down, network partition), load test ve end‑to‑end latency ölçümleri yapın. Chaos testing ile resiliency'i doğrulayın.

7. 7. Geo‑replication nasıl yönetilmeli?

   Cross‑region replication, eventual consistency ve conflict resolution politikalarıyla planlanmalıdır; latency ve egress maliyetleri göz önünde bulundurun.

8. 8. Mesajlaşma ile veri tutarlılığı nasıl korunur?

   Event sourcing, transactional outbox pattern ve exactly‑once semantics (kısıtlı senaryolarda) ile veri tutarlılığı sağlanabilir. Outbox pattern çoğu durumda pragmatic ve güvenli bir çözümdür.

Anahtar Kavramlar

Partition

Mesaj log'unun bölümlere ayrılmış parçası; ordering ve parallellism için kullanılır.

Offset

Partition içindeki sıra numarası; consumer progress'i belirler.

Outbox pattern

Veritabanı transaction'ı içinde mesaj yazıp daha sonra mesaj broker'a taşıyarak atomic publish sağlama tekniği.

Consumer group

Bir topic'i paylaşan ve partition'ları tüketen bir grup; paralel tüketim sağlar.

Dead‑letter queue (DLQ)

İşlenemeyen mesajların taşındığı kuyruk; hata analizi ve retry yönetimi için kullanılır.

Öğrenme Yol Haritası

1. 0–1 ay: Messaging temelleri: queue vs pub/sub, basic producer/consumer uygulamaları oluşturun (RabbitMQ veya Kafka ile basit örnekler).
2. 1–3 ay: Partitioning, consumer groups, offset management ve idempotency pattern'larını öğrenin; test environment kurun ve integration test yazın.
3. 3–6 ay: Stream processing araçları ve stateful processing (Kafka Streams, Flink) deneyin; outbox pattern ve transactional messaging uygulayın.
4. 6–12 ay: Production‑grade deployments: multi‑region replication, monitoring, capacity planning ve disaster recovery süreçlerini uygulayın.