Ing lorosing layanan, biasane sampeyan tuku-tukar konsistensi kuwat kanggo konsistensi eventual, lan gumantung ing CQRS lan event sourcing kanggo ndadiake iku praktis lan bener.
Sawise owah-owahan, replika konvergen "pronto" tinimbang instan. Katarmanan kanggo akeh alur bisnis (tembung inventaris bisa anteng sawetara detik), ora katarmanan kanggo sawetara (cek saldo bank).
Pisahake write model saka siji utawa luwih read models.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Bacaan skala lan mbentuk maneh bebasingan saka tulisen; read model dianyari saka acara, mula iku eventual konsisten.
Simpen urutan acara minangka sumber kasunyatan, ora mung kaanan saiki. Kaanan saiki iku lipatan marang acara.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Teknik | Golekan | Biaya |
|---|---|---|
| Eventual consistency | Sesiabilitas, skala | Baca lawas, konflik |
| CQRS | Skala baca/tulis | Loro model kanggo tetep sinkron |
| Event sourcing | Audit, replay, riwayat | Evolusi skema/acara, kerumitan |
Ora adopsi event sourcing ing kabeh – iku kuat nanging abot. Gunakake iku yen audit/riwayat pancen penting.
Sistem terpencil ora bisa duwe konsistensi kuat, sesiabilitas, lan toleransi partisi kabeh sakaligene, dadi desain senior babagan pili yen eventual consistency ditampa.
CQRS lan event sourcing menehi sampeyan alat kanggo ndadiake eventual consistency dipercaya lan audit – nanging saben-saben nambah kerumitan nyata, mula terapake kanthi bedil, ora sacara default.