Lintas layanan Anda biasanya menukar konsistensi kuat dengan konsistensi eventual, dan mengandalkan CQRS dan event sourcing untuk membuat hal itu praktis dan benar.
Setelah perubahan, replika konvergen "segera" daripada secara instan. Dapat diterima untuk sebagian besar alur bisnis (hitungan inventaris dapat tertinggal sekon), 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 dirancang ulang secara independen dari penulisan; read model diperbarui dari events, jadi konsistensinya eventual.
Simpan urutan events sebagai sumber kebenaran, bukan hanya state saat ini. State saat ini adalah hasil fold dari events.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Teknik | Keuntungan | Biaya |
|---|---|---|
| Eventual consistency | Ketersediaan, skala | Baca usang, konflik |
| CQRS | Skala baca/tulis | Dua model untuk disinkronkan |
| Event sourcing | Audit, replay, sejarah | Evolusi skema/event, kompleksitas |
Jangan terapkan event sourcing di mana-mana — itu kuat tetapi berat. Gunakan di mana audit/sejarah benar-benar penting.
Sistem terdistribusi tidak dapat memiliki konsistensi kuat, ketersediaan, dan toleransi partisi semua sekaligus, jadi desain senior adalah tentang memilih di mana 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 dengan bijak, bukan secara default.