Message queues 2026: Kafka, RabbitMQ, NATS, and making the right choice

[Aior]

Mesaj kuyruğu neden gerekli?​

Bir dağıtık sistemde mesaj kuyruğu temel iletişim katmanıdır. Synchronous REST/gRPC çağrılar tight coupling ve cascading failure üretir; mesaj kuyruğu loose coupling sağlar. AIOR olarak müşteri projelerinde kuyruğu sıkça önerdiğimiz senaryolar: e-posta gönderimi, görüntü işleme, üçüncü taraf API senkronizasyonu, audit logging, gerçek zamanlı bildirim, ETL pipeline.

Kafka — log-based streaming için​

Apache Kafka, distributed event streaming için en yaygın platform. AIOR projelerinde Kafka'yı tercih ettiğimiz durumlar:

• Yüksek throughput (saniyede milyonlarca mesaj).
• Persistent mesaj retention (saatler/günler boyunca tutma).
• Multiple consumer aynı mesaj akışını işliyor.
• Event sourcing pattern.
• Real-time analytics, log aggregation.

Ödünleşmeler:

• Operasyonel karmaşıklık — Zookeeper (eski) veya KRaft (yeni) ek katman.
• Setup ve scaling ciddi öğrenme eğrisi.
• Küçük sistemler için over-engineering.

AIOR'da managed Kafka tercih ediyoruz — Confluent Cloud, AWS MSK, Aiven. Self-hosted Kafka sadece veri lokasyonu zorunluluğu varsa.

RabbitMQ — traditional message broker​

RabbitMQ, AMQP protokolü üzerine kurulu olgun message broker. Kafka'dan farklı bir model — message-oriented (FIFO queue), Kafka log-oriented.

AIOR projelerinde RabbitMQ'yu tercih ettiğimiz durumlar:

• Klasik work queue pattern — task'lar worker'lara dağıtılır.
• Routing flexibility — exchange types (direct, topic, fanout, headers).
• Düşük-orta throughput.
• Setup ve operasyon basitliği önemli.
• Priority queues, dead letter queues yerleşik.

Pratik kullanım örneği: AIOR'da WordPress sitelerinin background job'ları (e-mail sending, image processing, third-party sync) RabbitMQ üzerinde.

NATS — lightweight ve hızlı​

NATS, CNCF projesi olarak büyüyen modern messaging system. Cloud-native ortamlar için tasarlandı. AIOR projelerinde NATS'i tercih ettiğimiz durumlar:

• Mikroservis service-to-service iletişim.
• Ultra-düşük latency (sub-millisecond).
• Lightweight footprint — Kubernetes pod başına az kaynak.
• Pub/sub, request-reply, queue group, JetStream (persistent).

NATS JetStream Kafka benzeri persistent streaming desteği; küçük-orta ölçekte alternatif.

Redis Streams — pragmatik orta yol​

Redis 5.0+ ile gelen Streams özelliği basit mesaj kuyruğu kullanımları için yeterli. Zaten Redis kullanan projeler için ekstra altyapı gerekmez. AIOR projelerinde tercih ettiğimiz senaryolar: WordPress + Laravel background job'ları, basit pub/sub, real-time notification.

Sınırlar: Kafka kadar büyük ölçekli değil; persistent retention sınırlı; clustering Redis Cluster gerektiriyor.

AWS SQS / SNS, Google Pub/Sub, Azure Service Bus​

Cloud-native managed messaging:

• AWS SQS — basit queue, FIFO veya standard.
• AWS SNS + SQS — fan-out pattern için.
• Google Pub/Sub — Kafka-benzeri, fully managed.
• Azure Service Bus — enterprise messaging, AMQP destekli.

AIOR projelerinde bulut tercihine göre seçim — managed servisler operasyon yükünden tasarruf sağlıyor.

Pattern'ler ve best practice'ler​

• At-least-once delivery — varsayılan; consumer idempotent olmalı.
• Exactly-once — Kafka idempotent producer + transactional consumer ile mümkün ama complexity yüksek.
• Dead letter queue (DLQ) — başarısız mesajlar için ayrı queue; sonradan inspection.
• Retry policy — exponential backoff, max retry count.
• Outbox pattern — DB transaction + message publish atomicity.
• Saga pattern — distributed transaction'lar için choreography veya orchestration.

Observability​

Mesaj kuyruğu sistemi observability olmadan kör çalışır. AIOR projelerinde standart metrikler:

• Queue depth (lag) — anormal değerler problem işareti.
• Throughput (msg/sec) — producer ve consumer ayrı.
• Latency (publish-to-consume) — p95/p99 percentile.
• Error rate — başarısız mesaj oranı.
• Consumer lag (Kafka'da) — consumer geride mi.

Prometheus exporter ile metrikler, Grafana ile dashboard. Sentry veya Datadog ile error tracking.

Test stratejisi​

Mesaj kuyruğu içeren sistemler test etmek zor. AIOR yaklaşımı:

• Unit testler — producer/consumer logic mock ile.
• Integration testler — testcontainers ile gerçek broker (RabbitMQ, Kafka).
• Contract testler — Pact ile producer/consumer kontrat.
• Chaos testler — broker outage simülasyonu.

Sonuç​

Mesaj kuyruğu seçimi proje karakterine göre yapılır. AIOR'da default: küçük-orta proje için RabbitMQ veya Redis Streams; yüksek throughput / event streaming için Kafka; ultra-hafif mikroservis için NATS; bulut-native için managed servisler. Yanlış araç seçmek operasyon kapasitenizi aşan complexity üretir. Sizin tarafınızda en sık karşılaştığınız mesaj kuyruğu sorunu ne — consumer lag, DLQ yönetimi, yoksa idempotency mi?

Why a message queue?​

In a distributed system, the message queue is the fundamental communication layer. Synchronous REST/gRPC calls create tight coupling and cascading failures; a message queue provides loose coupling. Cases where AIOR often recommends queues: email sending, image processing, third-party API sync, audit logging, real-time notifications, ETL pipelines.

Kafka — for log-based streaming​

Apache Kafka is the most widespread platform for distributed event streaming. Cases where AIOR picks Kafka:

• High throughput (millions of messages/second).
• Persistent message retention (hours/days).
• Multiple consumers processing the same message stream.
• Event sourcing pattern.
• Real-time analytics, log aggregation.

Trade-offs:

• Operational complexity — Zookeeper (old) or KRaft (new) as an additional layer.
• Setup and scaling have a steep learning curve.
• Over-engineering for small systems.

AIOR prefers managed Kafka — Confluent Cloud, AWS MSK, Aiven. Self-hosted Kafka only when data locality is mandatory.

RabbitMQ — traditional message broker​

RabbitMQ is a mature message broker built on AMQP. Different model from Kafka — message-oriented (FIFO queue), Kafka is log-oriented.

Cases where AIOR picks RabbitMQ:

• Classic work queue pattern — tasks distributed to workers.
• Routing flexibility — exchange types (direct, topic, fanout, headers).
• Low-to-medium throughput.
• Setup and operational simplicity matter.
• Priority queues, dead-letter queues built in.

Practical use: WordPress background jobs (email sending, image processing, third-party sync) at AIOR run on RabbitMQ.

NATS — lightweight and fast​

NATS is a modern messaging system growing as a CNCF project. Designed for cloud-native environments. Cases where AIOR picks NATS:

• Microservice service-to-service communication.
• Ultra-low latency (sub-millisecond).
• Lightweight footprint — minimal resources per Kubernetes pod.
• Pub/sub, request-reply, queue group, JetStream (persistent).

NATS JetStream provides Kafka-like persistent streaming; an alternative for small-to-mid scale.

Redis Streams — a pragmatic middle path​

The Streams feature in Redis 5.0+ is sufficient for simple message queue usage. Projects already using Redis don't need extra infrastructure. Cases where AIOR uses Redis Streams: WordPress + Laravel background jobs, simple pub/sub, real-time notifications.

Limits: not as large-scale as Kafka; persistent retention is limited; clustering requires Redis Cluster.

AWS SQS / SNS, Google Pub/Sub, Azure Service Bus​

Cloud-native managed messaging:

• AWS SQS — simple queue, FIFO or standard.
• AWS SNS + SQS — fan-out pattern.
• Google Pub/Sub — Kafka-like, fully managed.
• Azure Service Bus — enterprise messaging, AMQP-supported.

AIOR projects choose by cloud preference — managed services save operational overhead.

Patterns and best practices​

• At-least-once delivery — default; consumers must be idempotent.
• Exactly-once — possible with Kafka idempotent producer + transactional consumer but complexity is high.
• Dead letter queue (DLQ) — separate queue for failed messages; inspect later.
• Retry policy — exponential backoff, max retry count.
• Outbox pattern — DB transaction + message publish atomicity.
• Saga pattern — choreography or orchestration for distributed transactions.

Observability​

A message queue system runs blind without observability. Standard metrics on AIOR projects:

• Queue depth (lag) — abnormal values indicate trouble.
• Throughput (msg/sec) — producer and consumer separately.
• Latency (publish-to-consume) — p95/p99 percentile.
• Error rate — failed message percentage.
• Consumer lag (in Kafka) — is the consumer falling behind.

Metrics via Prometheus exporter, dashboards in Grafana. Error tracking via Sentry or Datadog.

Test strategy​

Systems with message queues are hard to test. AIOR's approach:

• Unit tests — producer/consumer logic with mocks.
• Integration tests — real broker (RabbitMQ, Kafka) via testcontainers.
• Contract tests — producer/consumer contracts via Pact.
• Chaos tests — broker outage simulation.

Bottom line​

Message queue choice follows project character. AIOR defaults: small-to-mid project → RabbitMQ or Redis Streams; high throughput / event streaming → Kafka; ultra-light microservice → NATS; cloud-native → managed services. Picking the wrong tool produces complexity that overruns your operational capacity. What's your most common message queue issue — consumer lag, DLQ management, or idempotency?