Selamlar,

CQRS yazımı da okuduğun için teşekkürler. "Eventual Consistent CQRS" görselinde implementasyon detayından kaçınmak için "Asynchronous Process" adında bir kutu yer almaktadır. Bu kutu herhangi bir yöntemle değişikliklerin okuma modeline yansıtılması gerektiğini göstermektedir. Senin senaryon için bu, mesajlaşma sisteminden mesaj okuyan ve okuma modelini güncelleyen bir servis olabilir. Başka bir senaryoda da yazma modeli güncellenirken fire-and-forget yapısında bir görevin tetiklenmesi de olabilir (Örneğin Hangfire kullanarak okuma modelinin güncellenmesi için bir görevin yaratılması). Aslında görselde bir eksiklikten ziyade bilinçli olarak implementasyon detayından kaçınmak için bir abstraction yapılmış durumda.

CQRS yapısı ile kurgulanmış sistemlerde okuma modeli sadece projeksiyon verisi olarak kullanılır. Bu veri üzerinden herhangi bir operasyon yürütülmez. Bu sebeple güncel olmayan okuma modeli sistemin yanlış bir aksiyon almasına sebep olmamalıdır (yani başımıza bela olmamalıdır). Örneğin stok yönetiminin asenkron olarak yapıldığını düşünelim. Yazma modelinde yer alan verileri - Event Sourcing ile birleştirilmiş durumdaki sistemler için olmuş olan olaylar da diyebiliriz - üst üste koyarak sistemdeki gerçek stok değerini elde ederiz. Ardından yeni satış talebini yerine getiririz veya getirmeyiz. Bu noktada okuma modelinde yer alan değere göre işlem yürütmemeliyiz. Bu konuyu tekrar belirtmek isterim.

Yazılımcı perspektifinde yukarıda örneklenen durumda bir hata olmadığını düşünmekteyiz. Kullanıcı tarafından baktığımız durumdaysa sorun olabilecek bir kaç nokta vardır. Stok örneğinden gidersek kullanıcılara okuma modelini kullanarak stok var gibi gösterebiliriz. Buna karşın sepete ürün eklenmeye çalışıldığı zaman "yetersiz stok" gibi bir hata ile ürün sepete eklenemeyebilir. Bu durum kullanıcı memnuniyetsizliği yaratabilir. Yazılımda çoğu konuda olduğu gibi bu da bir trade-off konusudur. Kullanıcıya o anki gerçek veriyi sunmak vs. kullanıcıya daha hızlı dönüşler yapmak.

Büyük yük altında çalışan sistemlerde mümkün olduğunca eventually-consistent yapılar kurulmaya çalışılır. Bu şekilde sistemler hazırlanırken hataları minimize etmek için entegrasyon, kontrakt, yük testleri gibi testler yazılır. Bunun yanı sıra servis durduğu için senkronizasyonun yapılamaması gibi durumların oluşmaması için servisler ve api'lar çeşitli monitoring araçları ile izlenmektedir. Yükün artması ile birlikte okuma ve yazma arasında senkronizasyon süresi artacaktır. Bu sürelerin belli seviyeleri aşmaması yani quality of service değerinin belli bir standart değerde kalması için de auto-scaling işlemleri yürütülmektedir. Kısacası büyük sistemlerde kullanıcıya belli kalitede hizmet vermek için yazılım tasarımının yanı sıra devops süreçlerinin de planlanması önem arz etmektedir.

Umarım yardımcı olabilmişimdir. Başka soruların olursa da yardımcı olmak isterim.

İyi çalışmalar dilerim