Olay tabanlı mimari (Event-Driven Architecture), servisler arasındaki bağımlılığı azaltmak için güçlü bir yaklaşımdır. Ancak bu esneklik; daha karmaşık hata senaryoları, eventual consistency ve operasyonel yük gibi yeni sorumlulukları da beraberinde getirir.

Her sistemin event tabanlı olması gerekmez. Gerçek fayda, aynı olaya birden fazla bağımsız servisin tepki verdiği senaryolarda ortaya çıkar.

Olayları gerçek ayrıştırma için kullanın

Bir sipariş oluşturulduğunu düşünelim.

Bu olay;

  • Notification Service
  • Inventory Service
  • Analytics Service
  • Billing Service

tarafından birbirinden bağımsız şekilde işlenebilir.

Bu durumda Order Service hiçbir tüketiciyi bilmek zorunda kalmaz. Yeni bir servis eklendiğinde üretici kodunda değişiklik yapılmasına gerek kalmaz.

Tek bir tüketici varsa ve doğrudan HTTP çağrısı yeterliyse, event kullanmak çoğu zaman gereksiz karmaşıklık oluşturur.

Replay ve idempotency’yi en baştan planlayın

Dağıtık sistemlerde aynı mesaj birden fazla kez teslim edilebilir.

Bu nedenle event consumer’ları idempotent olacak şekilde tasarlanmalıdır. Aynı OrderCreated olayı iki kez işlendiğinde sistemin durumu değişmemelidir.

Ayrıca bir servis günler sonra yeniden ayağa kalktığında eventleri güvenle tekrar işleyebilmelidir.

Outbox Pattern, Inbox Pattern ve Event Store gibi yaklaşımlar bu noktada önemli avantaj sağlar.

Olay sözleşmelerini yönetin

Event payload’ları servisler arasında bir sözleşmedir.

Schema değişiklikleri eski consumer’ları sessizce bozabilir.

Bu nedenle;

  • Event Versioning
  • Schema Validation
  • Backward Compatibility

gibi prensipleri uygulamak uzun vadede bakım maliyetini ciddi şekilde azaltır.

Başarısız mesajların gönderildiği Dead Letter Queue (DLQ) da mutlaka izlenmeli ve düzenli olarak incelenmelidir.

Sonuç

Event-Driven Architecture yüksek ölçekli sistemlerde güçlü bir araçtır ancak ücretsiz değildir.

Doğru tasarlanmış event sözleşmeleri, idempotent consumer’lar ve güçlü gözlemlenebilirlik olmadan sistem zamanla yönetilmesi zor hale gelebilir.

Gerçek ihtiyaç oluştuğunda event kullanın; yalnızca popüler olduğu için değil.