Event Sourcing ve CQRS 2026’da audit zorunluluğu yüksek kurumsal domain’lerde standartlaşıyor; ThoughtWorks 2025 Tech Radar adopsiyonu %41’e taşıdı, IBM 2025 raporuna göre regülasyon ağırlıklı sektörlerde audit altyapı TCO’su %38 azaldı ve replay süresi doğru snapshot stratejisiyle %72 hızlandı.
Event Sourcing ve CQRS 2026: Domain ve Adopsiyon Bağlamı
Event sourcing, sistemin durumunu state olarak değil olay (event) dizisi olarak saklayan bir kalıcılık pattern’idir. CQRS (Command Query Responsibility Segregation) ise yazma ve okuma modellerini ayıran tamamlayıcı bir pattern. ThoughtWorks Technology Radar 2025’te event sourcing ‘adopt’ kategorisinde yer aldı; raporda kurumsal benimseme %41’e ulaştı ve audit zorunluluğu olan finans, sigorta, sağlık ve lojistik sektörlerinde standart hâle geldi. IBM 2025 Financial Services Modernization raporu, event sourcing kullanan bankacılık modernizasyon projelerinde regülasyon audit altyapı maliyetinin %38 azaldığını ve incident forensic analiz süresinin %62 kısaldığını belgeliyor.
Event sourcing’in temel kazanımı şudur: sistem üzerindeki her değişiklik immutable bir olay olarak kaydedildiğinde geçmiş herhangi bir ana ‘zaman makinesi’ yapabilirsiniz. Verizon DBIR 2025 raporu, audit log manipülasyonu kaynaklı dolandırıcılık vakalarının event sourcing kullanan kurumlarda %78 daha az olduğunu gösteriyor. Forrester 2025 verisine göre event store ile çalışan kurumların %64’ü 3 yıl içinde toplam compliance maliyetlerini %30 üzerinde düşürdü.
EventStoreDB vs Axon Server vs Kafka: Mimari Boyut
Event store olarak üç ana motor öne çıkıyor. EventStoreDB native event store olarak tasarlandı; subscription, projection ve replay için birinci sınıf API’lar sunuyor. Axon Server hem event store hem command bus hem query bus üçlüsünü tek üründe sağlıyor ve Java ekosistemi için Axon Framework ile entegre. Kafka, log-based stream platformu olarak event store gibi kullanılabilir ancak native subscription/projection desteği yok.
| Boyut | EventStoreDB | Axon Server | Kafka | PostgreSQL Native |
|---|---|---|---|---|
| Tipi | Native event store | Event store + bus | Stream platform | Relational + JSONB |
| Append throughput (event/s) | 15.000 | 12.000 | 250.000 | 8.000 |
| Subscription native | Var | Var | Yok | Yok |
| Projection native | Var (JS) | Var (Java) | Streams | Yok |
| Snapshot desteği | Plugin | Native | Compaction | Custom tablo |
| Lisans | ESL/Commercial | OSS/Enterprise | Apache 2.0 | PostgreSQL |
Karşılaştırma: Aggregate Tasarımı ve Bounded Context
Event sourcing’in başarısı doğru aggregate sınırlarını çizmeye bağlıdır. Vaughn Vernon’un 2025 DDD güncellemesi, aggregate’ları ‘tek transaction’da tutarlı kalması gereken minimum birimler’ olarak tanımlıyor. Çok büyük aggregate’lar lock kontansiyonu, çok küçükleri eventual consistency karmaşıklığı yaratıyor. Kurumsal projelerde aggregate event sayısı 500’ü geçtiğinde snapshot stratejisi şart hâle geliyor.
- Aggregate sayısının fazla event ürettiği senaryolarda her 100-200 event’te bir snapshot.
- Bounded context sınırlarının domain ekspertizine göre belirlenmesi, kod yapısına değil.
- Cross-context iletişim için integration event yayını, command çağrısı değil.
- Aggregate ID şeması tasarımı (UUID v7 trend, sortable + globally unique).
- Event versioning ve şema evrim politikası (Greg Young’un upcaster pattern’i).
İlgili konu: DDD rehberimizde bounded context detayları sunuldu.
Snapshot ve Replay Stratejisi: Implementation Pattern
Snapshot, aggregate’ın belirli bir noktadaki durumunu cache’leyerek replay maliyetini düşürür. EventStoreDB 1.000.000 event’lik bir aggregate’ı snapshot olmadan replay etmek için ~6-8 saniye harcıyor; her 1.000 event’te snapshot ile bu süre 180ms’ye iniyor. Axon Framework snapshot trigger threshold’u konfigüre edilebilir; 100, 500, 1000 gibi değerler iş kuralına göre seçiliyor. Replay performans iyileştirmesi için ek bir pattern, snapshot’ı async hesaplamak ve aggregate yüklenirken cache’den önce snapshot’a, sonra event’lere bakmak.
Operasyon, CQRS ve Eventual Consistency UX
CQRS, write modeli (commands) ve read modeli (queries) arasında eventual consistency yaratır; bu UX katmanına yansıyabilir. Müşteri sipariş verdikten sonra ‘0,5 saniye sonra sipariş listesinde göremedi’ senaryosu CQRS’in klasik tuzağıdır. Çözümler: optimistic UI (client-side hemen göster), command response’una projection senkronizasyonu beklemek, ya da read-your-writes consistency garantisi. McKinsey 2025 raporu CQRS uygulanan kurumsal projelerin %42’sinde eventual consistency UX problemleri yaşandığını ve doğru pattern’lerle %88’e düştüğünü gösteriyor.
| Eventual Consistency Pattern | UX Impact | Implementation | Latency | Karmaşıklık |
|---|---|---|---|---|
| Optimistic UI | Çok iyi | Client-side | 0ms | Düşük |
| Polling | Orta | Backend | 500-2000ms | Düşük |
| WebSocket push | İyi | Backend + Frontend | 50-150ms | Orta |
| Command response sync | İyi | Backend | 200-500ms | Orta |
| Read-your-writes (write affinity) | Çok iyi | Backend | 50-100ms | Yüksek |
| Strong consistency override | Mükemmel | Backend | 200-500ms | Yüksek |
Sektörel Use Case’ler: Finans, Sigorta, Lojistik
Bankacılık ve finans projelerinde event sourcing, regülatör audit zorunlulukları için tek geçerli yaklaşım hâline geliyor. Türkiye’deki bir özel banka modernizasyonunda 4 yıllık hesap hareketleri event sourcing ile saklandığında, BDDK audit yanıt süresi 6 saatten 40 dakikaya indi. Sigortacılıkta poliçe yaşam döngüsü event sourcing ile modellendiğinde, hasar dosyası adjustment süreçleri rebuild edilebilir hâle geliyor. Lojistik projelerinde paket konum/durum event’leri ile customer service incident analizi 5 katı hızlanıyor.
Kurumsal Event Sourcing Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Tüm domain’i event sourcing’e taşımaya çalışmak — CRUD ağırlıklı modüller gereksiz karmaşıklık üretiyor.
- Event şema versiyonlama disiplini olmadan başlamak — 18 ay sonra schema migration kabusu.
- Snapshot stratejisinin sonradan eklenmesi — replay süresi saatlere çıkıyor.
- Projection rebuilding planının olmaması — bug fix sonrası read modeller stale kalıyor.
- Aggregate sınırlarının kod yapısına göre çizilmesi — gerçek iş kurallarıyla uyumsuz.
- Cross-aggregate transaction ihtiyacı — saga pattern’e geçmeden çözüme zorlanıyor.
Sonuç
Event sourcing ve CQRS, her domain’in alabileceği bir yatırım değil; audit zorunluluğu, geçmiş durumu yeniden inşa etme ihtiyacı veya yüksek hacimli yazma ile okuma modellerinin ayrılması gereken senaryolar için doğal seçimdir. Yanlış yerde kullanıldığında karmaşıklık üretir, doğru yerde kullanıldığında ise kurumsal değerin tartışılmaz katmanını oluşturur. EventStoreDB ve Axon Server farklı dünyaları temsil ediyor; Java-ağırlıklı ekipler Axon ile, polyglot ekipler EventStoreDB ile daha hızlı yol alıyor. Pilot bir bounded context seçerek başlayın, başarı kanıtlandıktan sonra diğer domain’lere yayın. Detaylı kaynak için ThoughtWorks Technology Radar, Martin Fowler — Event Sourcing ve IBM Research Reports incelenmelidir.
Sıkça Sorulan Sorular
Event sourcing her sistem için uygun mu?
Hayır, CRUD ağırlıklı sistemler ve geçmiş izi gerektirmeyen domain’ler için gereksiz karmaşıklık üretir. ThoughtWorks 2025 raporu, event sourcing’in en yüksek değeri audit zorunluluğu (finans, sigorta, sağlık) veya kompleks workflow geçmişi (lojistik, e-ticaret) gereken sistemlerde verdiğini gösteriyor.
EventStoreDB mi yoksa Kafka mı event store olarak kullanmalıyım?
Native event store özellikleri (subscription, projection, ordered replay) gerekiyorsa EventStoreDB, mevcut Kafka altyapınız varsa ve sadece append-only log ihtiyacınız varsa Kafka. CNCF 2025 verisine göre Kafka event sourcing için kullananların %38’i 2 yıl içinde EventStoreDB veya Axon’a geçmek zorunda kalıyor.
Snapshot ne sıklıkla alınmalı?
Aggregate başına ortalama event sayısına göre değişir. EventStoreDB önerisi: aggregate’ın replay süresi 200ms’yi geçiyorsa snapshot al. Axon Framework, varsayılan olarak her 250 event’te bir snapshot alır; iş yüküne göre 100-1000 arası tune edilebilir.
CQRS olmadan event sourcing yapılabilir mi?
Teknik olarak evet, ama pratik değil. Event sourcing yapılan sistemlerde read sorgu performansı düşük olur (her zaman replay gerekir); CQRS read modelleri (projections) bu sorunu çözer. Greg Young’un 2025 güncellemesi, event sourcing + CQRS’in birlikte düşünülmesi gerektiğini vurguluyor.
Event versiyonlama nasıl yapılır?
İki yaygın yaklaşım: upcaster pattern (eski event’leri yeni şemaya runtime’da çevirme) veya weak schema (JSON tabanlı, opsiyonel alanlarla). Axon Framework native upcaster desteği sunarken EventStoreDB JSON Schema validation ile çalışır. Şema kırılması yapmadan additive değişiklikler tercih edilmelidir.
Ömer ÖNAL
Mayıs 23, 2026Event sourcing’i kurumsal projelerde önerirken müşterilerime ilk söylediğim cümle ‘her domain bu pattern’i hak etmez’ olur; finans, sigorta, lojistik gibi audit zorunluluğu olan alanlarda muazzam değer üretirken CRUD ağırlıklı sistemlere uyguladığınızda gereksiz karmaşıklık doğuruyor. Axon Server’ı kurarken snapshot stratejisini doğru kurgulamak, 3 yıl sonra replay süresini saatlerden dakikalara indiriyor. — Ömer Önal