Yaklaşık 10 yıldır microservice mimariyle birlikte event-driven architecture (EDA) da pazarda dolaşıyor. Kafka, RabbitMQ, AWS EventBridge, Google Pub/Sub, SNS/SQS. Tüm bu teknolojiler aynı fikri satıyor: servisler birbirini direkt çağırmasın, event yayınlasın, dinleyenler iş yapsın.
Teoride güzel. Pratikte? Bazı projelerde mucize, bazılarında karmaşıklık makinesi. Bu yazıda hangisi ne zaman olduğunu anlatacağım.
Event-driven’ın gerçekten parladığı yerler
1. Multi-consumer senaryolar. Bir olayın 4-5 farklı consumer’ı olduğunda EDA rasyonel. Sipariş verildiğinde:
- Email gönderen servis
- Analytics sistemine event yazan servis
- Inventory’den stok düşen servis
- Loyalty points hesaplayan servis
- Fraud detection çalıştıran servis
Bu 5 servis sipariş servisini tek tek çağırsaydı, sipariş servisi herkesi bilmek zorunda olurdu. Event yayınlamak tek satır, consumer’lar kendi hızlarında çalışıyor.
2. Asenkron iş akışları. Kullanıcı “profil resmini yükle” dediğinde hemen cevap almalı, ama arka planda:
- Thumbnail generate edilecek
- Content moderation çalıştırılacak
- CDN’e yüklenecek
- User search index’i güncellenecek
Bu 4 işlem 3-4 saniye sürebilir. Event-driven ile kullanıcıya hemen 200 dön, arka planda işle.
3. Audit ve replay ihtiyacı. Finansal veya compliance gereksinimli sistemlerde her state değişikliği event olarak kaydediliyorsa, audit log native geliyor. Ayrıca “bu event’i 3 gün önceki state üzerine tekrar çalıştır” dediğinde replay mümkün.
4. Cross-service decoupling. 5 farklı servisi olan bir ürünün, her servisin birbirini bilmek zorunda kalmaması iyi. Event hub (Kafka, EventBridge) üzerinden iletişim kuran sistemler daha esnek değişiyor.
EDA’nın işe yaramadığı yerler
1. Tek consumer’lı basit iş akışları. “Sipariş geldiğinde email gönder” tek bir consumer olduğunda event hub kurmak gereksiz. Fonksiyon direkt çağırılabilir veya queue kullanılabilir (SQS yeter).
2. Tight transactional gereksinimleri. Banking, inventory reservation gibi “ya hep ya hiç” ihtiyaçları event-driven modelden kaçar. Eventual consistency burada kabul edilemez, synchronous transaction gerekir.
3. Küçük ekipler. Event schema yönetmek, event versioning yapmak, consumer monitoring kurmak ek operasyonel yüktür. 3 kişilik ekibin bu yükü taşıması verimsiz.
4. Real-time response gereken senaryolar. “Kullanıcı ödeme yaptı, hemen confirmation göster” türü akışlarda event-driven ile milliseconds’ı kaybedersin. Synchronous API daha iyi.
Sık yapılan 3 hata
Hata 1: “Event-driven yapıyoruz” ama gerçekte sadece message queue kullanılıyor. Consumer tek, event schema yok, replay yapılamıyor, audit log tutulmuyor. Bu sadece asynchronous RPC, EDA değil.
Hata 2: Event payload’ı eksik. Event yayınlıyorsun ama içinde sadece user_id: 123 var. Consumer her defasında user servisine gidip detayları soruyor. Bu event-driven değil, sadece notification. Doğru event “user created” değil, “user created with these fields: …” olmalı.
Hata 3: Versioning plansız. 6 ay sonra event schema’sı değişti. Mevcut consumer’lar kırıldı. EDA’da event schema’ları versiyonlu olmalı, backward-compatible değişmeli.
Pratik karar ağacı
Kendi projenizde EDA kullanıp kullanmamaya karar verirken:
- Kaç farklı consumer bu event’i dinleyecek? 1 ise gereksiz, 3+ ise mantıklı.
- Event replay ihtiyacı var mı? Audit, debug, migration için?
- Consumer’lar aynı takımın mı, farklı takımların mı? Farklıysa EDA iletişimi kolaylaştırır.
- Synchronous cevap gereken bir kullanıcı aksiyonu mu? Ise EDA yanlış araç.
- Ekip EDA operasyonlarını taşıyacak kapasitede mi? (schema registry, monitoring, alerting)
Bu soruların en az 3’ünde EDA’ya işaret varsa, uygulamak mantıklı.
Başlama tavsiyesi
Herkes Kafka ile başlamamalı. EDA’ya giriş için:
Level 1: AWS SQS + SNS. Basit queue/topic modeli, minimal operational overhead.
Level 2: AWS EventBridge veya Google Pub/Sub. Schema registry, fan-out, filter rules.
Level 3: Kafka. Gerçekten yüksek throughput, ordered event streaming gerekiyorsa.
Her proje Level 3 ile başlamamalı. Level 1 ve 2 birçok kullanım senaryosunu karşılıyor ve operasyonel olarak çok daha hafif.
Sonuç
Event-driven architecture güçlü bir tool ama her proje için değil. Multi-consumer fan-out, asenkron işlem akışları, audit log ihtiyacı olan projeler için ciddi değer katıyor. Küçük ekipler, tek consumer’lı senaryolar, tight transaction gereksinimli akışlar için ise gereksiz karmaşıklık.
Kararınızı “moda” değil “gerçek ihtiyaç” üstüne verin. Kaç consumer, ne kadar decoupling, ne seviyede replay ihtiyacı. Bu soruların cevapları mimariyi çiziyor.