CQRS Nedir? Modern Backend Mimarisinde Performans ve Ölçeklenebilirlik

CQRS (Command Query Responsibility Segregation), modern backend sistemlerde performans ve ölçeklenebilirliğin kritik olduğu durumlarda giderek daha sık kullanılan bir mimari desendir. Kısaca özetlemek gerekirse, CQRS veri okuma ve yazma işlemlerini ayırmayı önerir; klasik CRUD yaklaşımında olduğu gibi her işlemi aynı şekilde ele almak yerine, okuma ve yazma farklı şekilde tasarlanır.

İlk bakışta bu durum karmaşık gibi görünebilir: Zaten çalışan bir şeyi neden ayıralım? Ancak gerçek projelerde okuma ve yazma operasyonlarının gereksinimleri çok farklıdır. Örneğin, bir sistem binlerce okuma isteği alırken, yazma işlemleri çok daha az olabilir. Ya da yazma işlemlerindeki iş kuralları karmaşıklaştıkça, hızlı veri çekimi zorlaşır.

CQRS burada devreye girerek sistemin her bir parçasını ayrı ayrı optimize etmeye olanak tanır: Yazma işlemleri için karmaşık mantık, okuma işlemleri için ise hız ve kullanım kolaylığı ön plana çıkarılır.

CQRS Nedir? Basit Anlatımla

CQRS (Command Query Responsibility Segregation), sistemi iki ana parçaya bölen bir desendir:

• Command (Komutlar): Veriyi değiştiren işlemler
• Query (Sorgular): Veriyi okuyan işlemler

Ana fikir, okuma ve yazma işlemlerinin aynı veri modeliyle yapılmaması gerektiğidir.

Klasik CRUD mimarisinde her şey tek bir katmandan yürür: Aynı model hem veri oluşturma, hem güncelleme hem de okuma işlemlerini üstlenir. Bu başlangıçta kolaydır, ancak zamanla sınırları ortaya çıkar.

CQRS ise şu yaklaşımı önerir:

• Komutlar (Command) sadece sistemi değiştirir, veri döndürmez
• Sorgular (Query) sadece veri okur, sistemi değiştirmez

Örneğin:

• Sipariş oluşturmak: Command
• Sipariş listesini almak: Query

Bu ayrım sayesinde:

• Yazma iş mantığı sadeleşir
• Veri okuma hızlanır
• Sistem ölçeklenebilirliği artar

Sonuç olarak, tek bir evrensel model yerine iki ayrı model ortaya çıkar:

• Write model - yazma için
• Read model - okuma için

İki model yapısı, projenin ihtiyaçlarına göre tamamen farklı tasarlanabilir.

CQRS Nasıl Çalışır?

CQRS'nin temelinde güçlü bir fikir yatar: Veri değiştirme ve okuma işlemleri hem mantıksal hem de mimari olarak ayrılır. Yani sistem, komutları ve sorguları farklı şekillerde işler.

Komutlar (Command): Veri Değiştirme

Komutlar, sistemin durumunu değiştiren işlemlerden sorumludur. Bunlar:

• Kullanıcı oluşturmak
• Sipariş vermek
• Profil güncellemek
• Veri silmek

Komutlar her zaman bir değişiklik niyeti taşır:

• Veri döndürmez veya en fazla bir durum döndürür
• İş kurallarından geçer
• Doğrulama ve kontrolleri tetikleyebilir

Örneğin: CreateOrderCommand - sipariş oluşturma komutu.

Önemli: Komutlar veri okumak için kullanılmaz. Görevleri sadece sistemi değiştirmektir.

Sorgular (Query): Veri Okuma

Sorgular, okuma işlemlerini temsil eder:

• Veriyi değiştirmez
• Bir sonuç (liste, nesne, istatistik) döndürür
• Maksimum hız için optimize edilmiştir

Örneğin: GetOrdersQuery - sipariş listesini almak.

CQRS'te sorgular, hızlı veri çekimi için özel olarak hazırlanmış ayrı bir veri modelini kullanabilir:

• Denormalize veritabanı
• Cache
• Ayrı bir okuma replikası

Model Ayrımı: Write Model ve Read Model

CQRS'in temel özelliği iki modelin (write model ve read model) olmasıdır:

• Write Model: Komutlar için kullanılır
• Read Model: Sorgular için kullanılır

Write Model:

• Karmaşık iş kurallarını barındırır
• Normalize edilmiştir
• Veri doğruluğuna odaklanır

Read Model:

• Basitleştirilmiştir
• Denormalize olabilir
• Hızlı sorgular için optimize edilmiştir

Örneğin, bir e-ticaret sitesinde:

• Write Model, siparişleri, ürünleri ve kullanıcıları normalize olarak saklar
• Read Model, "kullanıcı adı ve toplam tutarla birlikte siparişler" gibi hazır görünümler sunar

Sistemde Veri Akışı

1. Kullanıcı bir komut gönderir (ör. sipariş oluştur)
2. Sistem komutu işler ve değişiklikleri kaydeder
3. Sonrasında read model güncellenir (bazen asenkron olarak)
4. Kullanıcı bir sonraki sorguda güncel verileri alır

Asenkronluk nedeniyle, read modeldeki veriler hemen güncellenmeyebilir. Buna eventual consistency (gecikmeli tutarlılık) denir.

Böyle bir yaklaşım esneklik sağlar, fakat daha dikkatli bir mimari gerektirir.

CQRS ve CRUD: Farklar Neler?

CQRS'in değerini anlamak için onu klasik CRUD (Create, Read, Update, Delete) yaklaşımıyla karşılaştırmak gerekir.

CRUD Nasıl Çalışır?

CRUD'da tüm işlemler için tek bir veri modeli kullanılır:

• Oluşturma
• Okuma
• Güncelleme
• Silme

Genellikle:

• Tek bir veritabanı
• Tek model yapısı
• Tek bir mantık katmanı

Örneğin, "Users" tablosu hem yazma hem okuma hem de güncelleme için kullanılır. Özellikle proje başında bu çok pratiktir.

CRUD Yaklaşımının Sınırlamaları

• Karmaşık iş mantığı: Model, doğrulamalar ve ilişkilerle zamanla karmaşıklaşır
• Performans sorunları: Aynı veri hem yazma hem okuma için kullanılır, oysa gereksinimler farklıdır
• Ölçeklenme zorlukları: Okuma ve yazma ayrı ayrı optimize edilemez
• Zor sorgular: Veri çekmek için karmaşık JOIN'ler gerekebilir

CQRS Bu Sorunları Nasıl Çözer?

CQRS sorumlulukları ayırır:

• Yazma işlemleri → komutlar ve write model üzerinden
• Okuma işlemleri → sorgular ve read model üzerinden

Avantajları:

• Farklı veritabanları kullanılabilir
• Okuma işlemleri daha hızlıdır (hazır veri sunulur)
• Yazma işlemleri temiz ve mantıklıdır
• Sistemin ölçeklenmesi kolaylaşır

Örneğin:

• Sipariş yazmak - karmaşık kontroller içeren bir işlem
• Sipariş okumak - hızlı, özetlenmiş verilerin sunumu

Farklar Ne Zaman Kritikleşir?

• Yüksek trafikli sistemlerde
• Çok sayıda okuma gerektiren servislerde (analitik, paneller)
• Karmaşık iş uygulamalarında (finans, e-ticaret)

Özetle:

• CRUD: Küçük projeler için hızlı başlar ve kolaydır
• CQRS: Daha karmaşıktır, fakat büyük ve büyüyen projelerde avantajlıdır

CQRS tamamen CRUD'un yerine geçmez - daha çok, basit modellerin yetmediği durumlar için sonraki mimari adımı sunar.

CQRS Mimarisi Pratikte Nasıl Uygulanır?

CQRS sadece yöntemleri ayırmak değil, aynı zamanda verinin saklanma, işlenme ve iletilme şekline dair bütünsel bir değişikliktir.

Veritabanı Ayrımı

Basit CQRS uygulamalarında tek bir veritabanı farklı modellerle kullanılabilir. Daha ileri seviyede ise veri fiziksel olarak ayrılır:

• Write database: Yazma için
• Read database: Okuma için

Bu yaklaşım şunları sağlar:

• Yazma işlemleri için tutarlılık ve işlem desteği
• Okuma işlemleri için hız ve ölçeklenebilirlik

Örneğin:

• Write DB → PostgreSQL
• Read DB → Elasticsearch veya Redis

Farklı Veri Modelleri

CQRS'de okuma ve yazma için modeller tamamen farklı olabilir.

Write Model:

• Normalize tablolar
• Sıkı yapı
• Karmaşık iş mantığı

Read Model:

• Toplu (aggregate) veriler
• Minimum ilişki
• Hazır görünümler

Örnek: Karmaşık JOIN'ler yapmak yerine read modelde şu veriler doğrudan tutulabilir:

• Kullanıcı adı
• Sipariş listesi
• Toplam tutar

Bu, sorgu hızını ciddi şekilde artırır.

Asenkronluk ve Eventual Consistency

CQRS'de, modeller arasındaki veri senkronizasyonu anlık değildir.

1. Komut, write modeli değiştirir
2. Sistem bir olay (event) üretir
3. Read model güncellenir (genellikle asenkron olarak)

Böylece eventual consistency ortaya çıkar: Veri geçici olarak eski kalabilir. Bu CQRS için normaldir, ama sistemin buna hazırlıklı olması gerekir.

Sistem Mimarisi Örneği

Tipik bir CQRS sistemi şöyle görünebilir:

• API komut ve sorguları alır
• Komutlar (Command) → Ayrı bir katmanda işlenir (Command Handler)
• Sorgular (Query) → Doğrudan read modele gider
• Olaylar → Read modeli günceller

Daha büyük sistemlerde ayrıca şunlar eklenebilir:

• Message broker (Kafka, RabbitMQ)
• Yazma ve okuma için ayrı servisler
• Cache mekanizmaları

CQRS'i tüm sistemde bir anda uygulamak şart değildir. Çoğu zaman öncelikle mantıksal ayrım yapılır, fiziksel ayrım veya ileri özellikler ihtiyaca göre eklenir.

CQRS ve Event Sourcing: İlişkisi Nedir?

CQRS, Event Sourcing deseniyle sıkça birlikte anılır. Her ne kadar farklı desenler olsa da, özellikle karmaşık sistemlerde birbirini tamamlar.

Event Sourcing Nedir?

Klasik sistemlerde verinin sadece mevcut durumu saklanır: Örneğin "kullanıcı bakiyesi = 1000". Event Sourcing'de ise durumu oluşturan tüm olaylar tutulur:

• Kullanıcı hesabına 500 TL ekledi
• Kullanıcı 200 TL'lik siparişi ödedi
• Kullanıcı 700 TL bonus aldı

Güncel durum, bu olayların toplamı olarak hesaplanır.

CQRS ve Event Sourcing Nasıl Birlikte Çalışır?

• CQRS → Komutlar veriyi değiştirir, sorgular veri okur
• Event Sourcing → Her değişiklik bir olay olarak kaydedilir

1. Sisteme komut gelir
2. Bir olay (ör. OrderCreated) üretilir
3. Olay kaydedilir
4. Read model olaylardan güncellenir

Neden Genellikle Birlikte Kullanılırlar?

• Değişim geçmişi: Sistemin herhangi bir anı geri yüklenebilir
• İzlenebilirlik ve denetim: Ne zaman, ne olduğu kayıtlardan görülebilir
• Read modellerde esneklik: Olaylardan read model baştan oluşturulabilir
• Ölçeklenebilirlik: Olaylar servisler arasında kolay aktarılır

Ne Zaman Kullanılır?

• Değişiklik geçmişi önemliyse (finans, lojistik)
• Sistem karmaşık ve dağıtık ise
• Yüksek ölçeklenebilirlik gerekiyorsa

Ancak bu yaklaşım mimariyi ciddi şekilde karmaşıklaştırır ve deneyim gerektirir. Her projede gerekli değildir; çoğu zaman tek başına CQRS yeterlidir.

CQRS'in Artıları ve Eksileri

CQRS çok güçlü avantajlar sunar, ancak ek karmaşıklık da getirir. Uygulamadan önce hem avantajları hem dezavantajları iyi değerlendirilmelidir.

CQRS'in Avantajları

• Ölçeklenebilirlik: Okuma ve yazma bağımsız ölçeklenebilir (ör. daha fazla okuma replikası eklenebilir)
• Yüksek performans: Read model sorgular için özel olarak optimize edilebilir (cache, denormalizasyon, hazır görünümler)
• Mimari esneklik: Yazma için SQL, okuma için NoSQL gibi farklı teknolojiler kullanılabilir
• Temiz iş mantığı: Write model sadece veri değişiminden sorumludur, görüntüleme mantığıyla yüklenmez

CQRS'in Dezavantajları

• Uygulama karmaşıklığı: Komutlar, handler'lar, olaylar, modeller... Bileşen sayısı artar
• Eventual consistency: Veriler anında güncellenmez, kullanıcı geçici olarak eski veri görebilir
• Hata ayıklama zorluğu: Asenkronluktan dolayı hata tespiti zorlaşır
• Küçük projelerde gereksiz yük: Basit sistemlerde CQRS gereksiz yere işleri zorlaştırabilir

CQRS ne "daha iyi" ne de "daha kötü"dür; doğru şartlarda kullanıldığında değer katar.

CQRS Kullanımı Ne Zaman Mantıklı?

CQRS her projede uygulanması gereken bir desen değildir. Doğru yerde kullanıldığında avantaj sağlar.

Yüksek Trafikli Sistemler

• Dashboard'lar
• Analitik uygulamalar
• Pazaryerleri
• Sosyal ağlar

CQRS okuma işlemlerini ayrı bir modele taşıyarak hız ve ölçeklenebilirlik getirir. Ana veritabanındaki yük azalır.

Karmaşık İş Mantığı

• Yazma işlemlerinde yoğun doğrulamalar
• İş kuralları ve bağımlılıklar

CQRS ile bu mantık izole edilebilir ve anlaşılır hale gelir.

Okuma ve Yazmanın Farklı Gereksinimleri Olduğunda

• Yazma kesin tutarlılık gerektirir
• Okuma hız ve esneklik ister

CQRS ile veri yazımı güvenli, veri okuma ise hızlı ve kolay yapılır.

Dağıtık Sistemler ve Mikroservisler

Modern sistem mimarisinde CQRS çok iyi uyum sağlar. Bu yaklaşımı daha derinlemesine keşfetmek için Mikroservisler ve Monolitler: 2025 için Mimari Karşılaştırma başlıklı makaleye göz atabilirsiniz.

• Servisler okuma ve yazmadan ayrı sorumlu olabilir
• Veri olaylar aracılığıyla yayılır
• Her parça kolayca ölçeklenebilir

CQRS Gereksiz Olduğu Durumlar

• Küçük projeler
• Basit iş mantığı
• Düşük trafik
• Sınırlı ekip kaynakları

Bu gibi durumlarda CQRS gereksiz yere geliştirme sürecini zorlaştırır.

Ana kriter: Eğer CRUD yaklaşımı yük veya karmaşıklık nedeniyle tıkanıyorsa, CQRS düşünülmelidir.

Projede CQRS Nasıl Uygulanır?

CQRS'e geçiş için tüm sistemi baştan yazmak gerekmez. Çoğu zaman adım adım, problemli alanlardan başlanır.

Kademeli Geçiş

En mantıklı yol hepsini bir anda değiştirmemektir. Şunlarla başlanabilir:

• Komut ve sorgu mantığının ayrılması
• Ayrı handler'ların tanımlanması
• Okuma işlemlerinin ayrı DTO veya görünümlerle optimize edilmesi

Bu aşamada bile CQRS'in faydaları görülmeye başlar.

Tüm Sistemi Değiştirmeden Mantık Ayrımı

CQRS kod seviyesinde de uygulanabilir:

• Komutlar için ayrı sınıflar/metodlar
• Sorgular için ayrı servisler

Örneğin:

• CreateOrderCommandHandler
• GetOrdersQueryHandler

Bu, kodun daha iyi yapılandırılmasına ve sorumlulukların ayrılmasına olanak tanır.

Mimarinin Kademeli Karmaşıklaştırılması

Sistem büyüdükçe ek olarak şunlar eklenebilir:

• Ayrı bir read model
• Cache mekanizmaları
• Asenkron olay işleme
• Message broker (Kafka, RabbitMQ)

Not: Sadece gereklilik olduğunda bu adımlar atılmalıdır.

Uygulamada Sık Yapılan Hatalar

• Çok erken karmaşıklaştırmak: Sistem basitken CQRS'e geçmek
• Eventual consistency'yi göz ardı etmek: Veri gecikmelerini hesaba katmamak
• Gereksiz mimari: Event Sourcing ve broker'ları ihtiyaç olmadan eklemek
• Sınırların belirsizliği: Komut ve sorgu ayrımının net olmaması

CQRS evrimsel bir mimari adımdır; başlangıç noktası değildir. Gücü, parça parça uygulanabilmesindedir.

Sonuç

CQRS, okuma ve yazma işlemlerini ayırarak sistemlerin daha hızlı, esnek ve ölçeklenebilir olmasını sağlayan bir mimari desendir. Özellikle yüksek yük ve karmaşık iş mantığı olan projelerde, klasik CRUD'un sınırlarını aşmak için idealdir.

Bununla birlikte CQRS, her proje için uygun değildir. Basit sistemlerde gereksiz yere karmaşıklık ve hata riski oluşturabilir. Bu yüzden, CQRS'i gerçekten çözüm sunabileceği durumlarda kullanmak gerekir.

Özet seçim rehberi:

• Küçük proje → CRUD ile devam et
• Yük ve karmaşıklık artıyorsa → CQRS'e geçişi düşün

En iyi yaklaşım, aceleci olmadan CQRS'i adım adım, fayda sağlayacağı alanlardan başlatarak uygulamaktır.