Mesajlaşma Desenleri
Mesajlaşma, servisleri zaman ve deploy açısından birbirinden ayırır. Queue bir işi bir consumer'a teslim etmeye, event stream ise olayları saklayıp birden fazla consumer'ın kendi hızında işlemesine daha uygundur.
Hızlı Karar
| İhtiyaç | Desen | Dikkat |
|---|---|---|
| Bir işi worker'a bırakma | Queue + competing consumers | Ack ve duplicate delivery |
| Bir olayı birçok tüketiciye duyurma | Pub/Sub veya event stream | Schema ownership ve replay |
| Sonuç beklenen mesajlaşma | Request-reply | Timeout ve correlation ID |
| Uzun süreli veri akışı | Partitioned event stream | Ordering key ve consumer lag |
Üretim Kontrol Listesi
- Problem: Mesaj coupling'i mi, burst absorption'ı mı, replay'i mi çözüyor?
- Çözüm: Delivery, ack, ordering, retry, DLQ, schema ve ownership net mi?
- Trade-off: Async yapı gevşek bağlantı sağlar; eventual consistency, duplicate ve operasyon maliyeti getirir.
- Hata durumu: Poison message, consumer lag, broker outage, out-of-order event ve retry storm ele alınmalı.
- Ölçüm: Queue depth, oldest message age, lag, processing latency, retry ve DLQ rate izlenmeli.
- Güvenlik/maliyet: Topic/queue erişimi, encryption, retention, payload PII'si ve broker storage maliyeti yönetilmeli.
Queue ve Event Stream
| Model | Tipik teknoloji | Semantik |
|---|---|---|
| Broker queue | RabbitMQ, AWS SQS, Azure Service Bus, Google Pub/Sub | Mesaj genellikle başarılı ack sonrası kuyruktan düşer |
| Event stream | Kafka, AWS Kinesis, Azure Event Hubs, NATS JetStream | Retention ve offset ile tekrar okunabilir |
Teknoloji seçimi yalnızca throughput'a göre yapılmaz. Ordering, retention, consumer sayısı, managed operasyon, replay, cross-region ve maliyet birlikte değerlendirilir.
Mesaj Desenleri
Request-reply
İstek mesajı correlationId ve reply destination taşır. Reply bekleme süresi deadline ile sınırlıdır; timeout sonrası geç gelen cevap business state'i yanlışlıkla tekrar yazmamalıdır.
Publish-subscribe
Producer bir topic'e event yayınlar, her consumer kendi subscription'ı üzerinden alır. Topic-based routing basit ve gözlemlenebilirdir; content-based filtering consumer sayısını azaltabilir fakat broker filtre maliyeti ve schema bağımlılığı ekler. Fan-out için consumer isolation ve retention planı gerekir.
Competing consumers
Aynı queue'yu tüketen worker'lar işi paylaşır. Mesaj key'i ordering gerektiriyorsa aynı aggregate'ın mesajları aynı partition/consumer'a yönlendirilmelidir. Worker concurrency, downstream connection pool ve database kapasitesini aşmamalıdır.
Event Routing ve Event-Driven Servisler
Routing kararı topic exchange, partition key, subject veya content filter ile yapılabilir. Routing key kararsız seçilirse hot partition veya ordering ihlali oluşur. Event producer yalnızca gerçekleşmiş domain gerçeğini yayınlamalı; consumer kendi projection veya side effect sorumluluğunu taşır.
Bir event birden fazla servisi tetiklediğinde choreography basit olabilir; kritik süreçlerde gözlemlenebilirlik ve compensation için orchestration daha görünürdür. Her event'in producer'ı, consumer'ı, schema sahibi ve deprecation planı kataloglanmalıdır.
Schema Evolution
Additive alan ekleme, unknown field toleransı ve default değerlerle backward/forward compatibility korunur. Alan silme, tip değiştirme veya anlam değiştirme yeni event version/type gerektirir. Consumer'lar bilinmeyen event version'ını güvenli biçimde quarantine etmelidir.
Schema registry veya merkezi katalog kullanılıyorsa compatibility mode CI'da kontrol edilir. Event payload'ı mümkün olduğunca küçük tutulmalı; hassas veriyi tekrar tekrar topic'lere kopyalamak yerine referans veya sınırlı projection kullanılmalıdır.
Retry, DLQ ve Exactly-Once
Transient hatalar için bounded retry, exponential backoff ve jitter kullan. Poison message retry bütçesini tüketirse DLQ'ya gönder; DLQ'da hata nedeni, deneme sayısı, ilk görülme zamanı ve güvenli replay bilgisi bulunmalıdır.
Exactly-once çoğunlukla broker transaction'ı ve consumer offset sınırı içindedir. Database, email veya payment gibi dış side effect'lerde idempotency key, unique constraint, inbox/outbox veya deduplication gerekir. “Exactly-once” ifadesi kapsamı yazılmadan kullanılmamalıdır.
Operasyon
Consumer deploy'unda graceful shutdown, in-flight ack ve replay davranışı test edilir. Queue age SLO'yu bozuyorsa yalnızca worker artırmak yerine downstream saturation, batch size, partition dağılımı ve backpressure incelenir.
İleri düzey uygulama ayrıntıları için Senkron vs Asenkron İletişim, Asenkron İşlemler ve Akış İşleme sayfalarına bakılabilir.