Geleneksel CRUD Darboğazlarını Aşmak: Yüksek Trafikli Sistemlerde CQRS Mimarisi

Yıllar içinde büyüyen, özellikle kapsamlı ERP entegrasyonları barındıran veya yoğun sipariş logları tutan sistemlerde geleneksel CRUD (Create, Read, Update, Delete) yaklaşımı bir süre sonra mimari bir engele dönüşür. Aynı veritabanı tablosu üzerinde hem saniyede yüzlerce yeni kayıt (Insert/Update) oluşturmaya çalışmak hem de karmaşık raporlama sorguları (Select/Join) çalıştırmak, kaçınılmaz olarak tablo kilitlenmelerine (Deadlock), artan CPU tüketimine ve yavaşlayan yanıt sürelerine yol açar.

Bu darboğazı aşmanın endüstri standardı yolu, veriyi yazma ve okuma sorumluluklarını birbirinden tamamen ayıran CQRS (Command Query Responsibility Segregation) desenini uygulamaktır.

CQRS Temel Felsefesi: Komutlar ve Sorgular

CQRS, sisteme gelen istekleri iki kesin çizgiyle ayırır:

1. Commands (Komutlar): Sistemin durumunu (state) değiştiren işlemlerdir. (Örn: SiparisOlustur, MusteriGuncelle). Komutlar asla geriye veri dönmez (sadece başarılı/başarısız bilgisini döner).

2. Queries (Sorgular): Sistemin durumunu değiştirmeyen, sadece veri okuyan işlemlerdir. (Örn: AylikSiparisLoglariniGetir).

Bu mantıksal ayrım, fiziksel veritabanı ayrımına kapı aralar.

Fiziksel Ayrım: Yazma (Write) ve Okuma (Read) Veritabanları

Gerçek bir CQRS uygulamasında, Command ve Query işlemleri için aynı veritabanını kullanmak yerine, her işin doğasına uygun farklı veri depoları tercih edilir.

• Write Database (Command Tarafı): Sadece veriyi hızlıca yazmakla ilgilenir. Genellikle 3NF (Third Normal Form) standartlarında, veri bütünlüğünün (Integrity) en üst düzeyde korunduğu ilişkisel veritabanları (RDBMS) kullanılır. Burada indexleme minimumda tutulur çünkü fazla index yazma hızını düşürür.

• Read Database (Query Tarafı): Arayüzlerin veya raporlama ekranlarının tam da ihtiyaç duyduğu formatta (denormalize edilmiş) verileri barındırır. Karmaşık Join işlemlerinden kaçınmak için veriler, okunmaya hazır "Düzleştirilmiş" (Flattened) dökümanlar halinde MongoDB, Elasticsearch veya özel olarak indekslenmiş SQL View tablolarında tutulur.

İki Dünya Nasıl Senkronize Olur? (Eventual Consistency)

Write veritabanına yeni bir sipariş eklendiğinde, bu bilginin Read veritabanına da yansıması gerekir. Bu işlem genellikle Event-Driven (Olay Yönelimli) bir altyapı ile çözülür.

1. Kullanıcı bir sipariş oluşturur.

2. Command servisi bu siparişi Write DB'ye kaydeder.

3. Kayıt başarılı olduğunda Message Broker'a (Kafka / RabbitMQ) bir OrderCreatedEvent fırlatılır.

4. Event'i dinleyen bir arka plan işleyicisi (Projector/Worker), veriyi alır, gerekirse başka verilerle birleştirir (zenginleştirir) ve arayüzün okuyacağı formata çevirerek Read DB'ye yazar.

Bu asenkron yapı, Eventual Consistency (Nihai Tutarlılık) kavramını doğurur. Veri Write tarafına yazıldıktan çok kısa bir süre sonra (genellikle milisaniyeler içinde) Read tarafına yansır. Bu gecikme, modern dağıtık sistemlerde kabul edilebilir bir durumdur.

CQRS'in Sistematiğe Sağladığı Avantajlar

• Bağımsız Ölçeklenebilirlik (Independent Scaling): Sisteminizde yazma işlemi az, ancak okuma işlemi çok fazlaysa (örneğin bir e-ticaret sitesinde ürün arama), sadece Read veritabanını ve Query mikroservislerini yatayda ölçekleyebilirsiniz (Scale-out).

• Performanslı Okuma (Optimized Reads): Okuma veritabanı, veriyi tam olarak ekranda gösterileceği formatta tuttuğu için kompleks SQL Join'lerine gerek kalmaz. Veri doğrudan çekilir.

• Güvenlik ve İzolasyon: Yazma ve okuma modelleri ayrıldığında, karmaşık iş kuralları (Business Logic) sadece Command tarafında kalır. Query tarafı sadece "aptal" bir okuyucuya dönüşerek sistem karmaşıklığını (Complexity) azaltır.

Ne Zaman Kullanılmamalı?

CQRS, basit CRUD işlemlerinin yeterli olduğu, düşük trafikli ve iş kurallarının karmaşık olmadığı projelerde "Over-Engineering" (aşırı mühendislik) sayılır. Bakım maliyetini ve kod karmaşıklığını artırır.

Özetle; Eğer uygulamanızda veritabanı kilitlenmeleri artıyor, sipariş logları tablolarınızdaki okuma sorguları yazma işlemlerini yavaşlatıyor ve monolitik veritabanınız bir darboğaza dönüşüyorsa, CQRS mimarisi sisteminize nefes aldıracak en güçlü neşterdir. Doğru uygulandığında, devasa veri yüklerini tereyağından kıl çeker gibi yönetmenizi sağlar.