Di seluruh layanan, anda biasanya menukar konsistensi kuat dengan konsistensi eventual, dan mengandalkan CQRS dan event sourcing untuk menjadikannya praktis dan benar.
Setelah perubahan, replika bertemu "segera" daripada secara instan. Dapat diterima untuk sebagian besar alur bisnis (hitungan inventaris dapat tertinggal satu detik), tidak dapat diterima untuk beberapa (pemeriksaan saldo bank).
Pisahkan write model dari satu atau lebih read models.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Bacaan diskalakan dan dibentuk ulang secara independen dari penulisan; read model diperbarui dari peristiwa, jadi konsisten secara eventual.
Simpan urutan peristiwa sebagai sumber kebenaran, bukan hanya status saat ini. Status saat ini adalah lipatan atas peristiwa.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Teknik | Keuntungan | Biaya |
|---|---|---|
| Eventual consistency | Ketersediaan, skala | Bacaan basi, konflik |
| CQRS | Skala baca/tulis | Dua model untuk disinkronkan |
| Event sourcing | Audit, putar ulang, sejarah | Evolusi skema/peristiwa, kompleksitas |
Jangan adopsi event sourcing di mana-mana — ini kuat tetapi berat. Gunakan di mana audit/sejarah benar-benar penting.
Sistem terdistribusi tidak dapat memiliki konsistensi kuat, ketersediaan, dan toleransi partisi semuanya sekaligus, jadi desain senior adalah tentang memilih tempat eventual consistency dapat diterima.
CQRS dan event sourcing memberi anda alat untuk membuat eventual consistency dapat diandalkan dan dapat diaudit — tetapi masing-masing menambah kompleksitas nyata, jadi terapkan secara bedah, bukan secara default.