Olay Güdümlü Mimari Nedir?

Komut ile olay arasındaki fark

Geleneksel bir sistemde sipariş servisi işini bitirince fatura servisine “fatura kes”, stok servisine “stoğu düş”, e-posta servisine “onay gönder” der. Bunlar komuttur: gönderen, alıcıyı tanır ve ondan bir şey ister. Yeni bir ihtiyaç (ör. sadakat puanı) eklendiğinde sipariş servisinin kodu da değişmek zorundadır.

Olay güdümlü mimaride sipariş servisi yalnızca bir olay yayınlar: “1042 numaralı sipariş oluşturuldu.” Olay geçmiş zamanda yazılır, değiştirilemez bir gerçeği bildirir ve kimseye emir vermez. Fatura, stok, e-posta ve sadakat servisleri bu olaya abone olur. Yeni bir dinleyici eklemek, yayıncıya dokunmayı gerektirmez.

{
  "id": "7f3c2a90-1d4e-4b7a-9c61-0e5b8f2d4a11",
  "type": "order.created",
  "occurredAt": "2026-10-03T09:41:12Z",
  "data": { "orderId": 1042, "customerId": 88, "total": "1499.90", "currency": "TRY" }
}

Benzersiz kimlik ve zaman damgası tesadüf değildir: kimlik, tekrar gelen olayları ayıklamak için; zaman, olayları doğru sırada yorumlamak için gerekir.

Pub/sub: bir olay, birçok dinleyici

Olayların dağıtımı genellikle yayınla-abone ol (publish/subscribe, pub/sub) modeliyle yapılır. Yayıncı olayı bir konuya (topic) gönderir; her abonelik olayın kendi kopyasını alır. Bu, işi tüketiciler arasında paylaştıran klasik mesaj kuyruğundan farklıdır: orada bir mesajı tek bir tüketici alır, burada her ilgili servis alır. Altyapı olarak RabbitMQ, Apache Kafka, bulut sağlayıcılarının pub/sub servisleri veya küçük ölçekte Redis kullanılabilir. Sistemler arası sınırda aynı fikir webhook olarak karşımıza çıkar: dış servis bir olay olduğunda size HTTP ile haber verir.

Bedeli: nihai tutarlılık ve görünmeyen akış

• Nihai tutarlılık (eventual consistency): Sipariş kaydedildiği anda fatura henüz yoktur; birkaç yüz milisaniye veya bir kuyruk gecikmesi sonra oluşur. Arayüz ve iş kuralları bu ara durumu hesaba katmalıdır.
• Tekrar ve sıra: Altyapıların çoğu olayları en az bir kez teslim eder ve her zaman sıralı teslim etmez. Abonelerin idempotent olması, sıranın önemli olduğu durumlarda da sürüm numarası veya zaman damgasıyla eski olayları ayıklaması gerekir.
• Akışın görünmezliği: Komutlarla kurulan bir sistemde çağrı zinciri koddan okunabilir; olaylarla kurulanda “bu olayı kim dinliyor?” sorusu ancak çalışma zamanında yanıtlanır. Bir isteğin servisler arasındaki yolunu görmek için dağıtık izleme neredeyse zorunlu hâle gelir.
• Şema evrimi: Olay formatı bir sözleşmedir. Bir alanı kaldırmak, haberdar olmadığınız bir aboneyi bozabilir; değişiklikler geriye uyumlu yapılmalı veya sürümlenmelidir.

Çift yazma sorunu ve outbox deseni

En sinsi hata şudur: servis siparişi veritabanına yazar, sonra olayı broker'a gönderir. İkisinin arasında süreç çökerse sipariş vardır ama olay hiç yayınlanmamıştır; sıralama tersine çevrilirse var olmayan bir sipariş için olay yayınlanabilir. İki ayrı sisteme atomik olarak yazmak mümkün değildir.

Yaygın çözüm transactional outbox desenidir. Olay, sipariş kaydıyla aynı veritabanı işlemi içinde bir “outbox” tablosuna yazılır. Ayrı bir süreç bu tabloyu okuyup olayları broker'a iletir ve iletilenleri işaretler. Böylece sipariş ile olay ya birlikte vardır ya hiç yoktur; iletici çökse bile bir sonraki çalışmasında kaldığı yerden devam eder.

Ne zaman gerekmez?

Olay güdümlü mimari, birbirinden bağımsız gelişen çok sayıda ekip ve servis olduğunda, bir olaya tepki veren işlerin sayısı arttığında ve anlık yanıt gerekmeyen süreçlerde parlar. Tek ekibin geliştirdiği, ağırlıklı olarak kayıt ekleme ve listeleme yapan bir yönetim paneli için ise ek bir broker, nihai tutarlılık ve dağıtık hata ayıklama, çözdüğünden fazla sorun getirir. Sık görülen orta yol, mikroservislere geçmeden tek bir uygulama içinde olay yayınlayıp dinlemektir.