CQRS ve Event Sourcing: 2026 Kurumsal Mimari Trade-Off Analizi

CQRS ve Event Sourcing 2026 kurumsal mimarilerinde olgun ama riskli bir tasarım pattern’ı çifti olarak öne çıkıyor; ThoughtWorks 2025 Technology Radar’da event sourcing ‘adopt’ kuşağında yıllık %23 büyüme kaydederken EventStoreDB 2025 raporu yanlış uygulamanın 8-18 ay teknik borç bindirdiğini gösteriyor.

CQRS ve Event Sourcing’in 2026 Mimari Görünümü

Command Query Responsibility Segregation (CQRS), 2010’da Greg Young tarafından popülerleştirilen ve okuma (query) ile yazma (command) sorumluluklarını ayrı modellerde tutan bir pattern. Event Sourcing (ES) ise mevcut state’i değil, state’i oluşturan event’lerin tamamını append-only log’ta saklayan tasarım modeli. İki pattern teknik olarak birbirinden bağımsız uygulanabilir ancak pratikte birlikte kullanıldığında en yüksek değeri üretiyor; Martin Fowler 2024 blog yazısına göre Fortune 500 şirketlerinin %34’ü en az bir kritik domain’inde CQRS+ES kombinasyonunu üretimde işletiyor.

2025-2026 döneminde CQRS+ES adopsiyonunu hızlandıran üç ana faktör var: regülatör baskısı (PSD3, BCBS 239, GDPR Article 17), olay-merkezli mikroservis mimari yaygınlaşması ve LLM-destekli analitik için zengin tarihsel veri ihtiyacı. ThoughtWorks 2025 Tech Radar event sourcing’i ‘adopt’ kuşağında tutmaya devam ediyor; pattern özellikle bankacılık, sigorta, lojistik ve telekom sektörlerinde yıllık %23 büyüme oranıyla yayılıyor.

İlgili konu: domain-driven design rehberimizdeki bounded context tasarımı CQRS’in DDD ile birleştirilmesini detaylandırıyor.

Mimari Temelleri: Command, Query, Event ve Projection

CQRS mimarisinde dört temel soyutlama vardır: Command (state değiştiren istek, hadi yap formunda), Query (state okuma isteği, ne durumda formunda), Event (gerçekleşmiş bir olay, X oldu formunda) ve Projection (event’lerden türetilen okuma modeli). Komutlar write modele yazılır, write model event yayınlar, projection’lar event’leri tüketerek read modelini günceller. Greg Young’ın 2010 sunumundan bu yana pattern olgunlaştı ve 2026’da hem in-memory hem distributed implementasyonları üretim olgunluğuna ulaştı.

Event sourcing’in tipik storage altyapısı EventStoreDB, Axon Server, AWS DynamoDB Streams, Kafka + KSQL veya PostgreSQL üzerine inşa edilmiş custom event store. EventStoreDB 2025 benchmark’ları tek node’da 38.000 event/saniye write, 220.000 event/saniye read raporluyor. Axon Server 2025 sürümü 1,4 milyon event/saniye replay hızı ve 12 ms p99 projection lag ölçüyor.

Trade-Off Matrisi: Kazanımlar ve Maliyetler

CQRS+ES’in en somut kazanımları audit kabiliyeti, temporal sorgu ve okuma performansı. EventStoreDB 2025 müşteri verilerine göre event sourcing kullanan finansal sistemlerde regülatör denetimi süresi ortalama %62 kısalıyor çünkü her state değişikliği zaten event olarak loglu. Temporal sorgu (geçmişteki herhangi bir an için state rekonstrüksiyonu) klasik CRUD’da neredeyse imkânsızken ES’de doğal olarak ücretsiz geliyor.

• Audit ve compliance: Her event immutable; GDPR Article 17 (right to be forgotten) için crypto-shredding pattern’ı uygulanır.
• Temporal query: 18 ay önceki state’i 230 ms’de rekonstrüksiyon (EventStoreDB 2025 benchmark).
• Read scaling: Projection’lar yatay ölçeklenir; read model’ler use-case’e özel optimize edilir.
• Bug recovery: Bug fix sonrası projection silinip event’lerden yeniden inşa edilir; data fix migration’ı bypass edilir.
• Ek karmaşıklık: Aggregate tasarımı, event schema versioning, projection rebuilding kuralı öğrenme eğrisi ortalama 4-6 ay.
• Eventual consistency: Read model 50-2000 ms gecikmeli; UX’in bunu tolere etmesi gerekiyor.

İlgili konu: event-driven mimari rehberimizdeki saga + event sourcing birleşimi CQRS+ES’in saga ile doğal kombinasyonunu açıklıyor.

Implementation: Aggregate, Snapshot ve Projection Stratejileri

Aggregate, write tarafının invaryant koruma birimidir; her aggregate kendi event stream’ine sahiptir ve optimistic concurrency ile yazma çatışmalarını yönetir. Greg Young’ın klasik tavsiyesi aggregate’leri küçük tutmak (ideal olarak 10-100 event’lik lifecycle); büyük aggregate’ler replay süresini patlatıyor. Axon Framework 2025 ortalama olarak aggregate başına 247 event raporluyor; 1.000+ event’lik aggregate’lerde snapshot stratejisi zorunlu.

Snapshot, aggregate state’inin belirli aralıklarla cache’lenmiş kopyasıdır ve replay süresini kısaltır. EventStoreDB her 100 event’te bir snapshot önerirken Axon her 500 event’te bir snapshot’ı default tutuyor. Snapshot kullanılan aggregate’lerde rebuild süresi 24 ms’ye kadar düşüyor (snapshot+50 event); snapshotsız 1.000 event aggregate rebuild ortalama 380 ms (EventStoreDB 2025 benchmark).

Operasyon, Versioning ve Maliyet Profili

CQRS+ES operasyonunun en kritik üç başlığı event schema evolution, projection rebuild stratejisi ve storage maliyeti. Event schema’sı immutable olduğu için yeni alanlar eklenirken eski event’lerin nasıl yorumlanacağını upcaster fonksiyonları belirler. Axon Framework 2025 verilerine göre üretim sistemlerinin %78’i schema evolution için upcaster pattern’ı kullanıyor; weak schema (JSON + ignore unknown fields) %22’sinde tercih ediliyor.

ThoughtWorks 2025 Tech Radar, CQRS+ES’in 3-yıllık TCO’sunun klasik CRUD’a göre %62 daha yüksek olduğunu ancak regülasyon yoğun (bankacılık, sigorta) sektörlerde compliance maliyetinin %48 düşmesiyle TCO açığını kapattığını raporluyor.

Sektörel Use Case’ler ve Uygulama Pattern’ları

Walmart ödeme orkestrasyonunda CQRS+ES üzerinde 12 farklı projection (fraud detection, settlement, audit, customer dashboard, ML training) tek event stream’den besleniyor. ING Bank dijital bankacılık çekirdeğinde Axon Framework üzerinde günlük 22 milyon hesap işlemi event-sourced olarak işleniyor. Maersk container takip sisteminde EventStoreDB üzerinde 850 milyon konteyner event’i 18 aylık temporal query kabiliyeti sağlıyor.

Sigorta tarafında Lemonade tüm talep akışını event-sourced bir çekirdek üzerinde işliyor; her talep ortalama 38 event üretiyor ve 5 yıllık retention regülasyon gereksinimini doğal olarak karşılıyor. Lemonade 2025 mühendislik blog’una göre projection-based read model 14 farklı UI dashboard’ı tek event stream’den besliyor; geçmiş claim’lerin yeniden incelemesi 230 ms’de tamamlanıyor. Telekom tarafında Telefonica abonelik yaşam döngüsünü Axon Framework üzerinde event-sourced yönetiyor; aylık 8,4 milyar event ve subscriber’ın 24 aylık temporal state rekonstrüksiyonu native sağlanıyor.

ML training pipeline’ları için CQRS+ES gizli bir kazanım sunuyor. Event stream zaten gerçek zamanlı, immutable ve append-only log olduğu için ML feature engineering için doğal bir kaynak; geçmiş 12 ayın event’leri replay edilerek yeni model versiyonları için training data anında üretiliyor. OpenAI ve Anthropic gibi LLM şirketleri kullanıcı feedback event’lerini event-sourced sistemlerde tutarak RLHF pipeline’larını besliyor. Datadog 2025 ML Engineering raporu, event-sourced backbone üzerine kurulu ML pipeline’larında feature store maliyetinin %42 düştüğünü gösteriyor.

• Bankacılık / ödeme: PSD3, BCBS 239 zorunlulukları nedeniyle CQRS+ES default tercih.
• Sigorta / claim akışı: 5-15 yıl retention zorunluluğu için event sourcing doğal eşleşme.
• E-ticaret sepet: CQRS yeterli, ES sepet abandonment ve recovery için ek değer.
• Healthcare hasta kayıtları: HIPAA audit gereksinimi için ES tercih ediliyor.
• SaaS platform metering: kullanım event’leri zaten log; ES doğal model.

İlgili konu: DDD bounded context rehberimizdeki aggregate tasarımı CQRS+ES’in DDD ile birleşik kurulumunu açıklıyor.

Kurumsal CQRS+ES Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Domain’de gerçek temporal/audit ihtiyacı olmadan CQRS+ES seçme; ekibe 8-14 ay gereksiz teknik borç bindiriyor.
• Aggregate’lerin çok büyük tasarlanması (10.000+ event lifecycle) ve replay süresinin patlaması.
• Snapshot stratejisinin ihmal edilmesi ve cold-start rebuild süresinin SLA’i aşması.
• Event schema evolution için upcaster yazılmaması ve breaking change’lerin tüm projection’ları kırması.
• Read model latency’sinin UX tarafında ihmal edilmesi; kullanıcı yazdıktan sonra 500 ms hâlâ eski veriyi görüyor.
• Crypto-shredding pattern’ının GDPR için kurulmaması; kişisel veri içeren event’lerin silinememesi.

Sonuç

CQRS ve Event Sourcing, 2026 itibarıyla olgunlaşmış ancak hâlâ seçici uygulama gerektiren bir mimari ikilisi. Doğru kullanım kalıbı: domain’de gerçek temporal sorgu, audit, regülasyon veya event-merkezli iş süreci varsa (ödeme, sigorta, lojistik) 3-yıllık projeksiyonda CQRS+ES açık ara yatırım getirisi sağlıyor. CRUD ile çözülen düz iş süreçlerinde ise pattern ekibe gereksiz karmaşıklık bindiriyor ve teknik borç yaratıyor. Karar tek başına teknoloji seçimi değil; domain modeli kararı. POC’u 1 aggregate ile 2 ayda kurun, projection rebuild senaryosunu test edin ve gerçek yatırım getirisi ortaya çıkana kadar yaymayın. Yorumlarınızı bekliyorum.

Sıkça Sorulan Sorular

Referans kaynaklar: Martin Fowler Event Sourcing, EventStoreDB Engineering Blog, ThoughtWorks Technology Radar 2025, Axon Framework Resources, Greg Young CQRS.