CQRS Nedir?
13 Ekim 2026 Salı
Veri Okuma ve Yazmayı Özgürleştiren Mimari
Yazılım geliştirmeye başladığımız ilk günden itibaren öğrendiğimiz en temel kalıp CRUD (Create, Read, Update, Delete) yaklaşımıdır. Bir veri tabanı tablosu veya veri modeli oluşturur; aynı model üzerinden hem yeni veriyi kaydeder hem de ekranlara basmak için bu veriyi sorgularız.
Küçük ve orta ölçekli sistemlerde bu yaklaşım mükemmel çalışır. Ancak sistem büyüdükçe, kullanıcı sayısı arttıkça ve iş kuralları karmaşıklaştıkça tek bir veri modelinin hem yazma hem de okuma yükünü taşıması imkânsız hale gelir.
Yazma operasyonları veri tutarlılığı (ACID), doğrulama (validation) ve karmaşık iş kuralları gerektirirken; okuma operasyonları ışık hızında yanıt, denormalize görünümler ve karmaşık arama yetenekleri ister. Her iki dünyayı tek bir veri modeline sıkıştırmaya çalışmak, performans darboğazlarına ve spagetti koda yol açar.
İşte veri dünyasındaki bu çatışmayı kökten çözen mimari tasarım kalıbı:
CQRS (Command Query Responsibility Segregation) Nedir?
CQRS, bir sistemdeki veriyi değiştirme (Command / Komut) operasyonları ile veriyi okuma (Query / Sorgu) operasyonlarını birbirinden tamamen ayıran bir mimari tasarım kalıbıdır.
Geleneksel mimarilerde okuma ve yazma işleri aynı veri nesneleri (DTO/Entity) ve aynı veri tabanı şeması üzerinden yürütülür. CQRS mimarisinde ise sistem ikiye bölünür:
- Command (Yazma Side): Sistemdeki verinin durumunu değiştiren operasyonlardır (CreateOrderCommand, UpdateUserProfileCommand). Bu kanal sadece iş kurallarını doğrular, veriyi yazar ve geriye herhangi bir veri nesnesi dönmez (sadece başarılı/başarısız durumu döner).
- Query (Okuma Side): Sistemden veri çeken operasyonlardır (GetCustomerOrdersQuery, GetProductListQuery). Bu kanal asla verinin durumunu değiştirmez (side-effect yaratmaz), sadece ekrana veya istemciye gereken formatta optimize edilmiş veriyi sunar.
CQRS Nasıl Çalışır?
CQRS uygulamanın iki temel seviyesi vardır:
- Mantiksal Ayrım (Single Database): Okuma ve yazma kod modelleri servis/uygulama seviyesinde ayrılır fakat arka planda aynı veri tabanı kullanılır. Bu, CQRS'e geçişin en basit adımıdır.
Fiziksel Ayrım (Dual Database): Yazma ve okuma veri tabanları tamamen birbirinden ayrılır.
- Yazma Veri tabanı: İlişkisel bir veri tabanı (PostgreSQL, MySQL) olabilir ve normalize edilmiş şema ile veri bütünlüğünü korur.
- Okuma Veri tabanı: Okuma hızını maksimuma çıkarmak için denormalize edilmiş bir NoSQL veritabanı (MongoDB, ElasticSearch veya Redis) olabilir.
- Eşitleme (Synchronization): Yazma tarafında oluşan değişiklikler, olaylar (Event-Driven Architecture) aracılığıyla okuma veri tabanına aktarılır ve okuma modelleri güncellenir.
CQRS Ne Zaman Kullanılmalı, Ne Zaman Kaçınılmalı?
CQRS güçlü bir silahtır, ancak her projeye uygulanacak bir "gümüş kurşun" değildir.
Ne Zaman Kullanılmalı?
- Asimetrik Okuma/Yazma Oranı: Sistemde okuma sayısı yazma sayısından katbekat fazlaysa (örneğin e-ticaret sitelerinde binlerce kişi ürüne bakarken az sayıda kişi satın alma yapar).
- Karmaşık İş Kuralları: Yazma operasyonlarının çok sayıda doğrulama ve iş mantığı içerdiği, okuma tarafının ise farklı ekranlar için tamamen farklı veri formatlarına ihtiyaç duyduğu sistemlerde.
- Yüksek Performans Gereksinimi: Okuma performansının milisaniyeler seviyesinde tutulması gereken devasa sistemlerde.
Ne Zaman Kaçınılmalı?
- Basit ve standart CRUD işlemleri yapan (yazma ve okuma modellerinin neredeyse aynı olduğu) uygulamalarda.
- Veri tutarlılığının (consistency) milisaniyelik gecikmeleri bile tolere edemediği basit finansal hareketlerde (Eventual Consistency riski nedeniyle).
- Küçük ekipler ve sınırlı bütçeli projelerde (mimarinin getirdiği bakım maliyeti faydasından fazla olur).
CQRS, yazılım mimarisinde "tek bir model her işe yarar" anlayışını yıkan, veri okuma ve yazma sorumluluklarını ait oldukları uzmanlık alanlarına bölerek sistemlerin devasa ölçeklere ulaşmasını sağlayan en olgun mimari modellerden biridir.