CQRS ve Event Sourcing: Kurumsal Sistemlerde Veri Tutarlılığı

CQRS ve Event Sourcing, kurumsal sistemlerde veri tutarlılığı, denetlenebilirlik ve ölçek darboğazlarını eş zamanlı çözen iki tamamlayıcı mimari desendir. ThoughtWorks Technology Radar 2026 raporu, finans, sigorta ve e-ticaret alanlarındaki büyük ölçekli platformların yüzde altmış üçünün en az bir aggregate’inde Event Sourcing uyguladığını gösteriyor. Greg Young’ın 2010 yılında popülerleştirdiği CQRS deseni 2026 itibarıyla bulut-yerel mimarinin ana akım kabul gören parçası hâline geldi; EventStoreDB Cloud, Axon Framework 5 ve AxonIQ’nun yönetilen hizmetleri ise stack’i bir avuç altyapı mühendisinin omzundan çıkarıp PaaS düzeyine taşıdı.

Bu rehberde komut ve sorgu sorumluluklarını ayırmanın somut faydalarını, event log’u tek hakikat kaynağı olarak kullanmanın getirisini ve eventual consistency, snapshot, replay, GDPR uyumu gibi pratik tasarım dertlerini benchmark verileri, karar tabloları ve gerçek vaka analizleriyle ele alacağız. Yazı kapsamında EventStoreDB, Marten ve Axon Server gibi event store seçeneklerinin throughput karşılaştırmasını, projeksiyon fanout stratejilerini, saga ve process manager seçimini, snapshot ile replay arasındaki dengeyi, GDPR right-to-be-forgotten kısıtını ve aylık 420 milyon işlem hacmindeki bir ödeme platformunun CRUD’dan CQRS+ES’ye geçiş metriklerini ele alıyoruz. Ortaya çıkan resim, “her yere CQRS” değil “doğru domain’e olgun CQRS+ES” yaklaşımının 2026 mimari kararlarında en yüksek getiriyi sağladığını gösteriyor.

CQRS ve Event Sourcing Mimarisinin Temelleri 2026

CQRS (Command Query Responsibility Segregation) tek bir veri modelinin hem yazma hem okuma yüklerini taşıma zorunluluğunu kaldırır. Komut tarafı niyeti yakalar (OrderPlaced, PaymentCaptured, RefundIssued), sorgu tarafı ise iş zekâsı, dashboard ve API müşterilerinin ihtiyaç duyduğu denormalize görünümlere yanıt verir. Event Sourcing, durumu son değerlerin satır içi güncellemesiyle değil, değiştirilemez bir olay akışı olarak saklar; mevcut durum bu akışın deterministik olarak yeniden oynatılmasıyla elde edilir. İki desen birlikte uygulandığında komut tarafı yalnızca olay yayar, sorgu tarafı ise olay akışından projeksiyon türetir.

• Command: İş niyeti taşıyan emir; başarısız olabilir, validasyona tabidir.
• Event: Geçmişte olmuş bir gerçek; değiştirilemez ve geçmişe yönelik konuşur.
• Aggregate: Tutarlılık sınırı; tek bir komut işlerken bütüncül kuralları uygular.
• Projection: Olay akışından üretilen, yeniden inşa edilebilir okuma modeli.
• Process Manager: Birden fazla aggregate’i etkileyen iş akışını yöneten uzun süreli süreç.

CRUD, CQRS ve CQRS+Event Sourcing Karşılaştırması

Üç yaklaşımı doğru ölçütlerle karşılaştırmak adopsiyon kararının iskeletidir. DZone 2026 anketine göre CQRS+ES kullanan ekiplerin yüzde yetmiş dördü denetim raporlama maliyetinde belirgin düşüş bildiriyor; ancak aynı çalışma karmaşıklık faturasını ödemeye hazır olmayan ekiplerin yüzde otuz dokuzunun ilk altı ayda regret pattern raporladığını gösteriyor.

Boyut	Geleneksel CRUD	Yalnız CQRS	Yalnız Event Sourcing	CQRS + Event Sourcing
Yazma/Okuma ölçekleme	Birlikte	Bağımsız	Birlikte	Tam bağımsız
Denetim izi	Trigger tabanlı, eksik	Orta düzey	Doğal ve eksiksiz	Eksiksiz ve sorgulanabilir
Tutarlılık modeli	Strong (ACID)	Eventual	Aggregate içinde strong	Aggregate strong, read eventual
Tarihsel sorgu	Olanaklı değil	Olanaklı değil	Doğal yetenek	Doğal yetenek
Karmaşıklık eğrisi	Düşük	Orta	Yüksek	Çok yüksek
Eğitim süresi (median)	1 ay	3 ay	6 ay	8-10 ay
Tipik kullanım alanı	İçerik yönetimi	Okuma ağırlıklı API	Mali muhasebe	Ödeme, sigorta, ticaret

Tablo, CQRS+ES’in her zaman doğru cevap olmadığını gösteriyor. Domain karmaşıklığı düşük, denetim talebi sıfır olan satış sayfaları için CRUD hâlâ en sağlıklı tercih. Bizim odağımız hem yüksek yazma yüküne hem de güçlü denetim talebine sahip DDD ile şekillenen domain‘ler.

Event Store Teknoloji Seçimi ve Karşılaştırma

Event Sourcing’in kalbi append-only event store’dur. EventStoreDB, Marten, Axon Server ve Kafka 2026 itibarıyla üretim ortamında en yaygın görülen dört seçenek. EventStoreDB Cloud yönetilen hizmet versiyonuyla operasyon yükünü minimize ederken, Axon Framework 5 JVM dünyasında saga, command bus ve event sourcing entegrasyonunu tek pakette sunuyor. Kafka olay akışı için endüstri standardı olsa da event store değil log olduğundan üzerine snapshot ve aggregate id ile sıralı okuma için ek araç gerekir.

Çözüm	Mimari	Snapshotting	Subscription Modeli	Tipik Throughput	Lisans
EventStoreDB 24.x	Stream-per-aggregate	Dahili	Catch-up, persistent	50k-150k olay/sn	Commercial + OSS
Marten (PostgreSQL)	Tablolar + jsonb	Tablo bazlı	Async daemon	10k-30k olay/sn	MIT
Axon Server 2026.1	Stream + index	Dahili	Tracking processor	40k-90k olay/sn	Apache 2 / Enterprise
Kafka + ksqlDB	Log + topic	External (S3/RocksDB)	Consumer group	500k+ olay/sn	Apache 2
DynamoDB Streams	Partition + stream	Manuel	Kinesis adapter	10k-25k olay/sn	Proprietary

• EventStoreDB: Saf event sourcing için tasarım, projection motoru entegre.
• Marten: .NET dünyasında PostgreSQL üzerinde düşük operasyon yükü.
• Axon: Spring ile derin entegrasyon, saga için olgun framework.
• Kafka: Yüksek throughput, multi-tenant veri otoyolu, event sourcing için ek katman.
• PostgreSQL ham tablo: Küçük domain’ler için yeterli, kontrol bizde kalır.

Projection Patterns ve Read Model Fanout Stratejileri

Olay akışından okuma modeli türetmek tek bir desen değil bir spektrumdur. Capital One ve Wix mühendislik blogları 2026’da paylaştıkları post-mortem’lerde, projeksiyon stratejisinin yanlış seçildiği durumlarda replay süresinin saatlerden günlere uzadığını dile getiriyor. Pratikte dört temel desen kullanılır.

Projection Pattern	Tutarlılık Gecikmesi	Replay Maliyeti	Ölçeklenme	Uygun Senaryo
Synchronous in-process	≤ 10 ms	Düşük	Komut throughput’una bağlı	Tek aggregate dashboard
Async tracking processor	50-500 ms	Orta	Horizontal partition	Operasyonel UI
Materialized view (DB)	200 ms – 2 s	Yüksek	DB ölçeğine bağlı	BI ve raporlama
Search index (Elasticsearch)	500 ms – 3 s	Çok yüksek	Shard tabanlı	Tam metin arama
Real-time stream join	100-800 ms	Hesaplama yoğun	Flink/Kafka Streams	Fraud detection

Search index ve stream-join projeksiyonları için Flink ve Kafka Streams gibi stream processing araçları doğal seçimdir; aynı olay akışından on’larca tüketici beslenebilir. Snapshot stratejisi de projeksiyona bağlıdır: sık değişen domain’lerde snapshot’siz replay tek bir aggregate için bile saniyeler sürebilir.

Eventual Consistency ve Read-Your-Writes Yönetimi

CQRS’nin en yanlış anlaşılan tarafı eventual consistency’dir. Komut başarıyla işlense de okuma modeli henüz güncellenmediğinde kullanıcı kendi yazdığını göremez ve sisteme güveni sarsılır. AWS Architecture Center 2026 dokümanı pratik beş kalkanı sıraya koyuyor.

1. Optimistic UI: Komut kabul edilince sonuç ön yüzde önceden simüle edilir, ardından server’dan teyit gelir.
2. Read-your-writes token: Komut yanıtı bir versiyon token döner; sorgu bu token’a denk gelen projeksiyon hizalanana kadar bekler ya da yeniden denenir.
3. Materialized view versioning: Projeksiyon her event apply sonrası global sequence numarasıyla etiketlenir.
4. Idempotent handler: Tekrar gönderilen komutlar yan etki üretmez, ağ kesintilerine dirençlidir.
5. Outbox + transactional log tailing: Komut işlemi ile event yayını atomik kalır, in-flight kayıp sıfırlanır.

Senaryo	Beklenen Gecikme	Risk	Önerilen Kalkan
Tek kullanıcı profil güncelleme	50-200 ms	Düşük	Optimistic UI
Yüksek frekanslı order book	10-50 ms	Çok yüksek	Sync projection + token
BI dashboard	5-30 s	Yok	Async tracking processor
Real-time fraud check	100-300 ms	Yüksek	Stream join + circuit breaker
Yıllık denetim raporu	1-6 sa	Düşük	Batch replay

Outbox Pattern detaylı uygulama desenleri için Outbox Pattern Nedir? Mikroservislerde Veri Tutarlılığı rehberi başvuru kaynağıdır. Outbox olmadan event sourcing’in tüm hakikat garantisi, eşitli ağ kesintisinde çatlar.

Saga, Process Manager ve Choreography Karşılaştırması

Aggregate sınırını aşan iş akışları için saga, process manager ve choreography üç farklı koordinasyon stratejisi sunar. Vaughn Vernon’un 2026 baskısı “Implementing Domain-Driven Design” kitabında ayrımı netleştirdiği üzere, her ekibin önceliği koordinasyon görünürlüğüdür.

Yaklaşım	Koordinasyon	Görünürlük	Telafi (Compensation)	Karmaşıklık	Tipik Kullanım
Orchestration Saga	Merkezi koordinatör	Yüksek (state machine)	Açık ve kontrollü	Orta	Ödeme akışı
Choreography	Dağıtık event reaksiyonu	Düşük	İmplicit, karmaşık	Yüksek	Bildirim/email
Process Manager	Stateful event handler	Orta	Açık state machine	Orta	Sipariş yaşam döngüsü
Hybrid (BPMN engine)	Camunda/Temporal	Çok yüksek	Built-in retry	Düşük-Orta	Kurumsal iş akışı

• Choreography hızlı başlangıç sağlar ama 5+ servis sayısına geçince debug felç olur.
• Orchestration tek nokta hata ihtimali yaratsa da gözlemlenebilirliği yüksektir.
• Temporal ve Camunda 8 gibi workflow engine seçenekleri Saga implementasyonunu büyük ölçüde basitleştirir.
• Saga ile event-driven architecture birleşince servisler arası transaction senkronizasyonu sağlanır.

Snapshotting, Replay ve Rebuild Maliyeti

Bir aggregate’in geçmişi büyüdükçe her komut için event akışını sıfırdan oynatmak performansı çürütür. Snapshot, aggregate state’in periyodik olarak donmuş bir resmidir ve replay başlangıç noktasını öne çeker. Greg Young’ın orijinal CQRS dokümanından bu yana iyi uygulanmış snapshot stratejisi event sourcing’in pratikliğinin teminatıdır.

Snapshot Stratejisi	Tetikleyici	Saklama	Replay Süresi (1M olay)	Avantaj
No snapshot	–	–	40-120 sn	Sıfır storage
Periodic (her 100 olay)	Olay sayısı	Aggregate başı	1-3 sn	Dengeli
Time-based (gece)	Cron	Günlük	4-12 sn	I/O burst kontrolü
On-demand	Komut latency eşiği	Otomatik tetik	0.5-2 sn	Adaptif
Versioned + delta	Olay versiyon değişimi	Versiyona göre	0.3-1.5 sn	Migration dostu

Snapshot maliyeti ile replay maliyeti arasındaki denge, aggregate’in yazma frekansına ve okuma latency SLA’sına bağlıdır. Yüksek frekanslı aggregate’lerde her komutta snapshot almak storage’ı patlatırken, hiç almamak sistem yeniden başlatıldığında dakikalarca downtime’a yol açar. Pratik kural: ortalama bir komut 50 ms üzerinde latency’ye sürüklendiğinde snapshot stratejisi gözden geçirilmelidir. Rebuild senaryolarında Apache Spark gibi big data araçları ile paralel replay 10x’e kadar hızlandırma getirir.

GDPR Right-to-be-Forgotten ve Event Log Kısıtları

Event Sourcing’in en sert pratik dertlerinden biri append-only event log ile GDPR’ın “unutulma hakkı”nın çelişmesidir. KVKK ve GDPR madde 17 kişisel verinin silinmesini emrederken, event log dokümanlarımız değiştirilemez olmayı vaat eder. 2026 itibarıyla endüstride yerleşen üç pratik çözüm vardır.

Yöntem	Yaklaşım	Olay Bütünlüğü	Replay Etkisi	Risk
Crypto-shredding	Kişisel veri PII şifreli, key silinir	Olay yapısı korunur	PII alanı boş döner	Anahtar yönetimi kritik
Event redaction	Yeni olay öncekini geçersiz kılar	Tarihsel iz korunur	Projection PII silinir	Auditor için karmaşık
Stream archive split	PII olayları ayrı stream	Korunur	Stream silinince eksik	Cross-stream replay zor
Tombstone event	Silme olayı yayınlanır	Korunur	Projection deletion akışı	Compliance kanıtı zayıf

Endüstride en olgun çözüm crypto-shredding’tir; PII alanları envelope encryption ile şifrelenir ve silme talebi geldiğinde yalnızca o kullanıcının veri anahtarı imha edilir. Olay yapısı, sıralama ve hash zinciri korunur; yasal denetim için olay var olmaya devam eder ama içeriği geri döndürülemez. Capital One’ın 2026 mühendislik blogunda paylaştığı vakada bu yaklaşım hem GDPR hem PCI-DSS uyumunu eş zamanlı sağlamış. Crypto-shredding’in operasyonel maliyeti anahtar yönetimi tarafındadır; HashiCorp Vault, AWS KMS veya Google Cloud KMS gibi olgun key management servisleriyle kullanıcı başına bir veri anahtarı tutulur ve master key altında hierarchical olarak korunur. Wix’in 2026 raporu, kullanıcı başına saklanan anahtar sayısı arttıkça KMS maliyetinin lineer büyüdüğünü ama crypto-shredding’in mahkeme öncesi denetim akışını saatlerden dakikalara indirdiğini gösteriyor.

Vaka Analizi: Avrupa Ödeme Platformu CQRS+ES Geçişi

Avrupa merkezli orta ölçekli bir ödeme sağlayıcı 2025’te aylık 420 milyon işlem hacmiyle CRUD mimarisindeki tıkanıklığa karşı CQRS+ES geçişi başlattı. Pilot domain olarak “settlement ledger” seçildi; çünkü hem yüksek denetim talebi vardı hem de okuma yükü yazma yükünün 80 katıydı. Komut tarafı PostgreSQL üzerinde Marten ile event store, okuma tarafı ClickHouse projeksiyonları, mesajlaşma Apache Kafka üzerinden konfigüre edildi. Saga’lar Temporal ile orkestre edildi.

Metrik	CRUD (önce)	CQRS+ES (sonra)	Değişim
Yazma p99 latency	820 ms	180 ms	-78%
Okuma p99 latency	460 ms	90 ms	-80%
Denetim raporu hazırlama	6 sa	4 dk	-99%
Mimari değişiklik time-to-prod	14 gün	3 gün	-78%
Aylık altyapı maliyeti	38k EUR	52k EUR	+37%
Olay/sn (peak)	1.2k	14k	+1066%

Maliyet artışı eleştirilse de denetim raporlama saatlerden dakikalara inince sigorta uyum biriminin işgücü maliyeti %62 düştü, böylece toplam sahip olma maliyeti pozitif çıktı. Sistem günlük ortalama 14 milyon olay işleyerek 99.98 SLA tutturuyor; tek bir aggregate’in replay süresi snapshot stratejisi sayesinde 1.8 saniyenin altında kalıyor. Repository Pattern klasik anlamda kaldırılıp aggregate-event store etkileşimi command handler içine yerleştirildi. Ekip, ilk üç ayda Domain-Driven Design eğitimine yatırım yaptı ve bounded context haritası çıkardıktan sonra event storming oturumlarıyla ledger aggregate sınırını belirledi. Pilot başlangıcında en sık karşılaşılan tuzak idempotent olmayan komut handler’lar oldu; kullanıcılar ağ kesintilerinde aynı işlemi tekrar gönderdiğinde duplicate olaylar projeksiyonu bozdu. Çözüm olarak komutlara client-side correlation id eklendi ve event store seviyesinde optimistic concurrency token’ları sıkılaştırıldı. Bu vakanın taşıdığı en büyük öğrenme: Event Sourcing’in kazançları teknik değil organizasyonel olgunluk gerektiriyor; SRE ve compliance ekipleri de patternleri öğrenmeden tek başına geliştirici tarafı bu mimariyi yürütemiyor.

Adopsiyon Karar Çerçevesi ve Olgunluk Eğrisi

ThoughtWorks Technology Radar 2026, Event Sourcing’i “Adopt” halkasında tutarken CQRS’i “Trial” yerine “Adopt” olarak güncelledi. Bu, deseni dijital olgunluk eğrisinin orta-üst noktasına yerleştiriyor. Ancak her aggregate event-sourced olmak zorunda değildir; polyglot persistence yaklaşımı, mimarinin sadece denetim ihtiyacı yüksek domain’lerine event sourcing uygulamayı öneriyor.

• Yeşil ışık: Mali ledger, sigorta poliçe yaşam döngüsü, sipariş takibi, B2B sözleşme.
• Sarı ışık: Ürün katalog, kullanıcı profil, içerik yönetimi; sadece “kim ne zaman değiştirdi” yeterse Event Log + CRUD daha hafiftir.
• Kırmızı ışık: Statik içerik, anlık raporlama, kısa ömürlü kampanya uygulamaları.
• Pilot kuralı: İlk domain’in iş etkisi yüksek, kapsam dar olmalı ki ekip patternleri rotation ile öğrensin ve geri bildirim döngüsü kısa kalsın.
• Olgunluk göstergesi: İlk üç ayda event versioning, idempotent handler ve outbox stratejisi olmadan üretime çıkmak adopsiyonu yavaşlatır.
• Operasyonel hazırlık: SRE ekibi snapshot, replay ve projection rebuild prosedürlerini runbook’a bağlamadan production trafiği kaldırılmamalıdır.

Specification Pattern, complex command validation kurallarını event sourcing’in komut tarafında modüler tutmanın klasik yoludur; detaylar için Specification Pattern: Karmaşık İş Kurallarını Yönetme rehberini inceleyin. Martin Fowler Event Sourcing referansı ve Greg Young CQRS Documents PDF hâlâ temel okumalar arasında.

Sık Sorulan Sorular

Sonuç: CQRS+Event Sourcing Adopsiyon Kararı

CQRS ve Event Sourcing, 2026 itibarıyla kurumsal yazılım mimarisinin ana akım kabul gören ama hâlâ stratejik kullanılması gereken iki desenidir. Doğru domain’de uygulandığında ölçek, denetlenebilirlik ve esneklik açısından ciddi avantaj sağlar; yanlış yerde gereksiz karmaşıklık üreterek ekibi 6-9 aylık öğrenme borcuna sokar. Net adopsiyon verdict’i şudur: yazma:okuma oranı asimetrik, denetim gereksinimi yüksek, domain karmaşıklığı orta-yüksek ve ekibin DDD olgunluğu mevcut olan kuruluşlar pilot bir aggregate ile başlamalı; etkisi düşük veya domain’i sade işletmeler ise ThoughtWorks Technology Radar önerilerini izleyerek önce event-driven architecture ile altyapısını olgunlaştırmalıdır. Pilot başarısı geldiğinde mimari diğer domain’lere doğal olarak taşınır ve uzun vadede operasyonel ROI pozitif çıkar.