Giriş
Modern yazılım sistemlerinde ölçeklenebilirlik, performans ve veri tutarlılığı en kritik gereksinimler arasında yer alır. Geleneksel CRUD (Create, Read, Update, Delete) yaklaşımları, karmaşık iş süreçleri ve yüksek trafikli uygulamalarda yetersiz kalabilir. Bu noktada CQRS (Command Query Responsibility Segregation) ve Event Sourcing devreye girer.
Bu kapsamlı rehberde, her iki mimari desenin detaylarını, avantajlarını, dezavantajlarını ve gerçek dünya uygulamalarını inceleyeceğiz.
CQRS Nedir?
Temel Kavram
CQRS (Command Query Responsibility Segregation), komut ve sorgu sorumluluklarını ayıran bir mimari desendir. Bu desen, sistemdeki okuma (query) ve yazma (command) işlemlerini birbirinden bağımsız olarak ele alır.
Temel Prensipler
- Command (Komut): Sistemin durumunu değiştiren işlemler. Örneğin:
CreateOrder,UpdateCustomer,DeleteProduct - Query (Sorgu): Veri okuma işlemleri. Hiçbir yan etkisi olmaz, sadece veri döndürür
- Sorumluluk Ayrımı: Okuma ve yazma modelleri tamamen ayrıdır ve farklı veri kaynakları kullanabilir
Geleneksel Yaklaşım vs CQRS
Geleneksel CRUD Yaklaşımı
Tek bir model hem okuma hem yazma işlemlerini yönetir. Aynı veritabanı şeması, aynı entity'ler ve aynı business logic kullanılır. Bu yaklaşım basit senaryolar için idealdir ancak karmaşıklık arttıkça problemler ortaya çıkar.
CQRS Yaklaşımı
Okuma ve yazma için farklı modeller kullanılır. Write model, business logic ve veri tutarlılığından sorumludur. Read model ise sorgu performansı için optimize edilmiştir. Bu ayrım, her iki tarafın da bağımsız olarak ölçeklenmesini sağlar.
CQRS'in Avantajları
Avantajlar
- Performans Optimizasyonu: Okuma ve yazma veritabanları ayrı olduğu için, her biri kendi ihtiyacına göre optimize edilebilir
- Ölçeklenebilirlik: Okuma ve yazma yükleri farklı sunuculara dağıtılabilir
- Basitleştirilmiş Sorgu Modelleri: Read model, UI ihtiyaçlarına göre özel olarak tasarlanabilir
- Güvenlik ve İzinler: Okuma ve yazma işlemleri için farklı güvenlik politikaları uygulanabilir
- Paralel Geliştirme: Okuma ve yazma ekipleri birbirinden bağımsız çalışabilir
CQRS'in Dezavantajları
Dezavantajlar
- Karmaşıklık Artışı: İki farklı model yönetmek, basit CRUD yaklaşımından daha karmaşıktır
- Eventual Consistency: Yazma ve okuma veritabanları arasında senkronizasyon gecikmesi olabilir
- Öğrenme Eğrisi: Ekip üyelerinin CQRS prensiplerini anlaması ve uygulaması zaman alır
- Altyapı Maliyeti: İki ayrı veritabanı ve senkronizasyon mekanizmaları ek maliyet getirir
Event Sourcing Nedir?
Temel Kavram
Event Sourcing, uygulamanın durumunu güncel bir snapshot olarak saklamak yerine, durumu değiştiren tüm olayları (events) sıralı bir şekilde saklar. Mevcut durum, bu olayların teker teker uygulanmasıyla elde edilir.
Banka Hesabı Örneği
Geleneksel yaklaşım: Sadece güncel bakiyeniz saklanır (5.000 TL)
Event Sourcing: Tüm işlem geçmişi saklanır:
- +10.000 TL (maaş)
- -2.000 TL (kira)
- -500 TL (market)
- -2.500 TL (fatura)
Güncel bakiye bu olayların toplamıdır.
Event Sourcing'in Temel Bileşenleri
Event
Geçmişte olan ve değiştirilemeyen bir olay. Her event bir timestamp, event tipi ve ilgili veriler içerir.
Örnek Event'ler
OrderPlaced: { orderId: 123, customerId: 456, items: [...], totalAmount: 1500 }PaymentProcessed: { orderId: 123, amount: 1500, paymentMethod: "credit-card" }OrderShipped: { orderId: 123, trackingNumber: "ABC123", shippingDate: "2024-01-15" }
Event Store
Tüm event'lerin append-only şekilde saklandığı veritabanı. Hiçbir event silinmez veya güncellenmez, sadece yeni event'ler eklenir.
Aggregate
Domain-driven design (DDD) konsepti. İş kurallarını uygulayan ve event'leri üreten domain nesnesi.
Projection
Event stream'inden okuma modeli oluşturma işlemi. Event'ler işlenerek materialized view'lar oluşturulur.
Event Sourcing'in Avantajları
Avantajlar
- Tam Denetim İzi (Audit Trail): Her değişiklik kaydedilir
- Zaman Yolculuğu: Sistemin herhangi bir zamandaki durumu yeniden oluşturulabilir
- Event Replay: Hatalı bir business logic düzeltildiğinde, tüm event'ler yeniden oynatılabilir
- Debugging ve Hata Analizi: Bir hatanın nasıl oluştuğu, event geçmişine bakılarak anlaşılabilir
- İş Zekası ve Analitik: Tüm event'ler analiz edilerek içgörüler elde edilebilir
- Esneklik: Yeni raporlama ihtiyaçları için geçmiş event'ler yeniden işlenebilir
Event Sourcing'in Dezavantajları
Dezavantajlar
- Karmaşık Sorgular: Mevcut durumu elde etmek için event'lerin replay edilmesi gerekir
- Event Store Boyutu: Tüm event'ler saklandığı için depolama maliyeti artar
- Event Schema Evrimi: Event yapısının değişmesi durumunda geriye dönük uyumluluk zordur
- Öğrenme Eğrisi: Event-driven düşünme biçimi, geleneksel CRUD'dan farklıdır
- Snapshot Yönetimi: Performans için periyodik snapshot'lar alınmalıdır
CQRS ve Event Sourcing Birlikte Kullanımı
Neden Birlikte Kullanılır?
CQRS ve Event Sourcing birbirini tamamlayan desenlerdir. Event Sourcing, CQRS'in write tarafı için mükemmel bir çözümdür. Event'ler, command'ların sonucu olarak üretilir ve read model'i güncellemek için kullanılır.
Akış
Gerçek Dünya Uygulamaları
E-Ticaret Sistemi
Senaryo
Milyonlarca ürün, yüzbinlerce günlük sipariş alan bir e-ticaret platformu.
CQRS Uygulaması
- Write Model: Sipariş oluşturma, ödeme işleme, stok güncelleme
- Read Model: Ürün listeleme, arama, filtreleme, kullanıcı siparişleri
Event Sourcing Events
OrderPlaced- Sipariş verildiPaymentProcessed- Ödeme alındıInventoryReserved- Stok ayrıldıOrderShipped- Kargo verildiOrderDelivered- Teslim edildi
Kazanımlar
- Ürün arama için ayrı Elasticsearch kullanımı
- Sipariş geçmişi ve müşteri davranış analizi
- İade ve iptal işlemlerinde tam izlenebilirlik
Finansal Sistemler
Senaryo
Banka hesap yönetimi, para transferleri, kredi kartı işlemleri.
Event Sourcing Avantajları
- Her işlem kaydedilir, denetim kolaylaşır
- Hesap özeti = tüm işlemlerin toplamı
- Hatalı işlemler geri alınabilir (compensating events)
- Düzenleyici gerekliliklere uyum
Teknoloji Stack ve Araçlar
Event Store Çözümleri
- EventStoreDB: Event sourcing için özel geliştirilmiş açık kaynak veritabanı
- Apache Kafka: Yüksek throughput, distributed event streaming platformu
- Azure Cosmos DB: Change feed ile event sourcing desteği
- PostgreSQL: JSON/JSONB ile event store implementasyonu
Message Broker'lar
- RabbitMQ: Esnek routing, dead letter queues, priority queues
- Apache Kafka: Yüksek throughput, log-based architecture
- Azure Service Bus: Cloud-native, managed service
- Amazon SQS/SNS: AWS ekosistemi entegrasyonu
İmplementasyon Best Practices
Event Design Prensipleri
Temel Kurallar
- Event İsimlendirme: Geçmiş zamanda, gerçekleşen eylemi açıklayacak şekilde
- Event Granularity: İş anlamına sahip, atomik değişiklikleri temsil etmeli
- Event Immutability: Event'ler hiçbir zaman değiştirilmemeli
- Event Versioning: Geriye dönük uyumluluk için versioning stratejisi
Eventual Consistency Yönetimi
Problem
Write ve read model senkronizasyonu zaman alır. Kullanıcı, yaptığı işlemin sonucunu hemen göremeyebilir.
Çözümler
- UX Tasarımı: "İşleminiz alındı" mesajı
- Optimistic UI: UI'yi event gerçekleşmeden önce güncelleme
- Correlation ID: İşlem durumu takibi
- WebSocket: Real-time bildirimler
Snapshot Stratejisi
Binlerce event'i replay etmek yavaş olabilir. Çözüm: Periyodik snapshot'lar.
- Belirli sayıda event sonrası (her 100 event)
- Zaman bazlı (günlük snapshot)
- Aggregate yüklendiğinde asenkron
Anti-Patterns ve Yaygın Hatalar
1. God Aggregate
Hata: Çok fazla sorumluluk taşıyan aggregate
Sonuç: Performans problemi, karmaşık business logic
Çözüm: Aggregate'leri küçük, cohesive sorumluluklar etrafında tasarla
2. Event Store'u Sorgu Veritabanı Olarak Kullanma
Hata: Event store'dan doğrudan karmaşık sorgular
Sonuç: Yavaş sorgular
Çözüm: Read model kullan
3. Business Logic Read Model'de
Hata: Event handler'larda karmaşık business logic
Sonuç: Business kuralları dağılır
Çözüm: Tüm business logic aggregate'lerde
Performans Optimizasyonu
Read Model Optimizasyonu
- Denormalization: JOIN maliyetini azalt
- Materialized Views: Aggregation'ları önceden hesapla
- Caching: Redis ile sık erişilen verileri cache'le
- Sharding: Büyük veri setlerini dağıt
- Read Replicas: Okuma yükünü dağıt
Write Model Optimizasyonu
- Command Validation: Gereksiz event üretimini önle
- Bulk Processing: Event'leri batch olarak işle
- Asenkron İşlem: Event processing asenkron
- Partitioning: Write throughput artır
Ne Zaman Kullanılmalı?
CQRS Uygun Senaryolar
- Yüksek okuma/yazma oranı (10:1+)
- Karmaşık domain logic
- Farklı kullanıcı grupları, farklı view'lar
- Yüksek performans gereksinimi
- Mikroservis mimarisi
Event Sourcing Uygun Senaryolar
- Tam audit trail gereksinimi (finans, sağlık)
- Zaman yolculuğu ve historical analysis
- Event-driven architecture
- Karmaşık iş süreçleri ve saga'lar
Uygun Olmayan Senaryolar
- Basit CRUD uygulamaları
- Küçük takımlar, sınırlı kaynak
- Eventual consistency kabul edilemez
- Hızlı prototip geliştirme
Sonuç ve Öneriler
CQRS ve Event Sourcing, modern yazılım sistemlerinde ölçeklenebilirlik, performans ve veri tutarlılığı sağlamak için güçlü mimari desenlerdir. Ancak her sistem için uygun değillerdir ve dikkatlice değerlendirilmelidirler.
Başlangıç Önerileri
- Küçük Başlayın: Önce CQRS'i basit haliyle uygulayın
- Bounded Context Seçimi: İzole, düşük riskli domain seçin
- Ekip Eğitimi: Event-driven thinking öğretin
- Monitoring İlk Gün: Monitoring altyapısını baştan kurun
- Iterasyon: Küçük adımlarla ilerleyin
Önemli Noktalar
- CQRS ve Event Sourcing paradigma değişimi gerektirir
- Karmaşıklık maliyeti göz ardı edilmemeli
- Her proje benzersizdir, one-size-fits-all yoktur
- Ekip yetkinlikleri ve proje gereksinimleri dengelenmeli
Başarıya ulaşmanın anahtarı, ekibinizin yetkinlikleri, projenin gereksinimleri ve uzun vadeli hedefleriniz arasında doğru dengeyi kurmaktır. Küçük adımlarla başlayın, sürekli öğrenin ve sistemlerinizi iteratif olarak geliştirin.