Event-Driven Dedik Ama Queue Bir Entegrasyon Oldu

İlk kuyruğu eklediğimizde slaytta 'event-driven' yazıyordu. Sipariş servisi bir mesaj basıyor, stok servisi işliyor, sonucu başka kuyruğa bırakıyordu. Çağıran, korelasyon numarasıyla o sonucu bekliyordu. Kullanıcı hâlâ ekranda, 4 saniye, timeout, retry. Buna event demek, taksi çağırmaya yürüyüş demek gibiydi.

Event, olan biteni anlatır. {OrderPlaced}. Dinleyenler kendi işini görür. Yayınlayan, kimlerin dinlediğini bilmek zorunda değildir. Cevap bekliyorsa bu bir komut; kuyruk sadece taşıma. Taşıma değiştirmek, ilişkiyi değiştirmez.

Cevap bekleyen mesaj

Aşağıdaki şekil sık gördüğüm 'olay'. İsimler event gibi, alanlar RPC gibi. {replyTo} duruyorsa konuşma hâlâ iki kişilik ve senkron beklentili.

{
  "type": "ReserveStock",
  "orderId": "ord_18f2",
  "sku": "SKU-440",
  "qty": 2,
  "replyTo": "orders.reserve-replies",
  "correlationId": "ord_18f2:reserve",
  "timeoutMs": 4000
}

Bunu kuyruğa koymak, stok servisinin yavaş gününde checkout'u da yavaşlatır. Üstüne bir de 'en az bir kez' teslimat gelince, aynı rezervasyon iki kez uygulanır. Event-driven slaytı, idempotent olmayan bir RPC'yi gizlemiş olur.

Ne zaman bu şekil durur? Karşı tarafın cevabı aynı istek içinde ürün kararıysa. Stok yoksa satmayacaksanız, kullanıcıya hemen söylemeniz gerekir. O zaman kuyruk kazanç değil, jitter. Direkt çağrı, timeout ve net bir hata daha dürüst.

Asıl event nasıl durur

Sipariş kabul edildikten sonra stok düşecek, mail gidecek, fatura kesilecek. Kullanıcı 'sipariş alındı' görür. Bundan sonrası dinleyenlerin işi. Yayınlayan, mail servisinin ayakta olup olmadığına bakmaz.

{
  "type": "OrderPlaced",
  "orderId": "ord_18f2",
  "customerId": "cus_9",
  "lines": [{ "sku": "SKU-440", "qty": 2 }],
  "placedAt": "2026-04-06T08:30:00Z"
}

Burada {replyTo} yok. Stok yetmezse ne olur? O ayrı bir hikâye: ya stok siparişten önce senkron doğrulanır, ya da sonradan iptal/kompansasyon vardır. İkisini de 'kuyruk koyduk' diye atlamak, gece iptal mailleri üretir.

Kuyruğu entegrasyon yapan şeyler

• Yayınlayan, tüketicinin adını bilir ve onu bekler.
• Mesaj bir soru içerir: reserve, calculate, render.
• Korelasyon kimliği, cevabı kullanıcı isteğine bağlar.
• Tüketici yoksa yayınlayan hata sayar.

Bunların hepsi meşru olabilir. Meşru olmayan, bunların üzerine event rozeti yapıştırmak. Rozet, ekibi yanlış cesaretlendirir: 'artık gevşek bağlıyız'. Halbuki iki taraf hâlâ el sıkışıyor, sadece eldiven kuyruk.

Ne zaman kuyruk tutuyorum

Kuyruğu üç yerde tutuyorum. Bir: iş uzun ve kullanıcı beklememeli. İki: karşı tarafın düşmesi beni düşürmemeli. Üç: aynı olayın birden fazla dinleyeni var ve ben onları tek tek çağırmak istemiyorum. Üçü de yoksa kuyruk, log'u ikiye böler.

Emre'nin retry yazısındaki gibi, taşıma katmanı işi iki kez yapabilir. Event diye satılan komutta bu, çift rezervasyon olur. O yüzden kuyruk varsa idempotency konuşması aynı PR'da biter, 'sonra bakarız' demez.

İsimlendirme de teşhis. {ReserveStock} komut, {StockReserved} olay. İkisini aynı topic'te karıştırmak, tüketicinin ne yapacağını belirsizleştirir. Belirsiz tüketiciler, 'biraz daha alan ekleyelim' diye sözleşmeyi şişirir.

Event-driven olmak bir altyapı seçimi değil, bir ilişki seçimi. Kim kimi bekliyor? Cevabı kuyruk değiştirmiyorsa, slayttaki kelimeyi değiştirin. Kelime doğru olunca tasarım da sıkılaşıyor.