Hizmetler arasında genellikle güçlü tutarlılığı eventual tutarlılıkla değiş tokuş edersiniz ve bunu pratik ve doğru hale getirmek için CQRS ve event sourcing'e başvurursunuz.
Bir değişiklikten sonra kopyalar anında değil "yakında" birleşir. Çoğu iş akışı için kabul edilebilir (envanter sayısı bir saniye gecikebilir), bazıları için kabul edilemez (banka bakiyesi kontrolü).
yazma modelini bir veya daha fazla okuma modelinden ayırın.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Okumalar yazışlardan bağımsız olarak ölçeklenebilir ve yeniden şekillendirilir; okuma modeli olaylardan güncellendiği için, eventually consistent'tır.
Yalnızca mevcut durumu değil, olayların dizisini gerçeğin kaynağı olarak saklayın. Mevcut durum, olaylar üzerinde bir fold'dur.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Teknik | Kazanımlar | Maliyetler |
|---|---|---|
| Eventual consistency | Kullanılabilirlik, ölçeklenebilirlik | Eski okumalar, çatışmalar |
| CQRS | Okuma/yazma ölçeklendirmesi | İki modeli senkronize tutmak |
| Event sourcing | Denetim, tekrar oynatma, geçmiş | Şema/olay evrimi, karmaşıklık |
Event sourcing'i her yerde benimsemeyin — güçlüdür ama ağırdır. Denetim/geçmiş gerçekten önemli olduğu yerlerde kullanın.
Dağıtılmış sistemler güçlü tutarlılığa, kullanılabilirliğe ve bölüm toleransına aynı anda sahip olamaz, bu nedenle senior tasarım eventual consistency'nin nerede kabul edilebilir olduğunu seçmekle ilgilidir.
CQRS ve event sourcing size eventual consistency'yi güvenilir ve denetlenebilir hale getirmenin araçlarını verirler — ancak her biri gerçek karmaşıklık ekler, bu nedenle onları varsayılan olarak değil, cerrahi bir şekilde uygulayın.