Pada sistem terdistribusi, perubahan tidak selalu terlihat di semua tempat pada saat yang sama. Eventual consistency menerima jendela sementara ketika salinan berbeda, dengan syarat ada mekanisme yang membawa data menuju keadaan yang disepakati. “Nanti juga sama” bukan desain jika tidak ada batas waktu, aturan konflik, dan cara membuktikannya.
Mengapa ketidaksamaan sementara terjadi?
Perubahan melewati jaringan, antrean, proses validasi, dan sistem yang dapat berhenti sementara. Satu tujuan mungkin menerima update lebih cepat daripada yang lain. Bahkan dalam satu database, cache atau replica dapat menunjukkan waktu berbeda. Memaksa semua komponen selesai sebagai satu operasi dapat menaikkan latensi dan mengurangi ketersediaan.
Pertanyaan bisnisnya adalah berapa lama perbedaan dapat diterima. Status pembayaran mungkin memerlukan batas ketat, sedangkan dashboard agregat dapat tertinggal beberapa menit. Kaitkan dengan service tier integrasi, bukan satu definisi konsistensi untuk semua data.
Apa yang membuat data akhirnya konvergen?
Sistem memerlukan identitas record, urutan atau versi, aturan penerapan perubahan, retry untuk kegagalan sementara, serta rekonsiliasi untuk gap. Jika dua pihak dapat mengubah field sama, tentukan otoritas atau aturan resolusi. Last-write-wins mudah dibuat tetapi dapat menghapus perubahan yang secara bisnis lebih penting.
| Strategi | Kelebihan | Risiko |
|---|---|---|
| Satu sumber kebenaran | Konflik lebih sederhana | Sumber menjadi dependensi utama |
| Versi monotonik | Update lama dapat ditolak | Perlu generator versi tepercaya |
| Merge per field | Menjaga perubahan independen | Aturan bisnis lebih kompleks |
| Review manusia | Cocok untuk konflik bernilai tinggi | Tidak otomatis dan lebih lambat |
Bagaimana menjelaskan status kepada pengguna?
Jangan menampilkan “selesai” ketika sistem hanya menerima request. Gunakan status seperti diterima, sedang diproses, tersinkron, perlu perhatian, atau gagal—disesuaikan bahasa bisnis. Pengguna juga perlu tahu apakah aman mengirim ulang dan di mana melihat hasil. Status teknis tidak harus dibuka, tetapi makna serta tindakan berikutnya harus jelas.
Hindari sukses palsu dengan memisahkan acknowledgment transport dari hasil bisnis. Ini penting ketika proses berlanjut setelah respons awal.
Seperti apa contoh pada inventory?
Toko mengurangi stok setelah penjualan, lalu pusat menerima perubahan beberapa saat kemudian. Selama jendela itu, stok pusat belum sama dengan toko. Jika event terlambat atau duplikat, pusat memakai identitas transaksi dan versi agar tidak mengurangi dua kali. Batch rekonsiliasi membandingkan saldo dengan transaksi sumber.
Ketika pusat juga dapat menyesuaikan stok, konflik memerlukan aturan: perubahan mana yang merupakan transaksi, koreksi, atau stock opname. Menjumlahkan semua perubahan tanpa jenis dapat menghasilkan saldo salah. Dokumentasikan pemilik melalui sumber kebenaran data.
Apa yang harus diukur dan direkonsiliasi?
- Usia perubahan tertua yang belum tersinkron.
- Jumlah record tertunda per kelas bisnis.
- Persentase konvergen dalam batas waktu.
- Konflik yang membutuhkan keputusan manusia.
- Selisih jumlah dan total nilai antar-sistem.
- Waktu pemulihan setelah dependensi kembali.
Gunakan rekonsiliasi data untuk menemukan silent gap yang tidak terlihat dari error rate.
Kapan eventual consistency dapat diterima?
Terima bila bisnis menyetujui jendela ketidaksamaan, operasi dapat dibuat idempoten, konflik memiliki aturan, dan ada bukti konvergensi. Jangan gunakan untuk menyamarkan proses yang seharusnya membutuhkan keputusan atomik atau persetujuan sebelum efek terjadi. Dokumentasikan konsekuensi saat batas waktu terlewati.
Platform workflow seperti NitroNet dapat membantu membuat tahapan dan hasil terlihat, tetapi artikel ini tidak menyatakan implementasi konsistensi tertentu. Uji desain dengan gangguan, duplikat, dan event terlambat. Lanjutkan ke out-of-order events untuk memahami salah satu sumber ketidaksamaan paling umum.
Pilih satu field yang disalin ke beberapa sistem dan minta pemilik bisnis menentukan batas waktunya. Jangan mulai dari kemampuan teknologi. Definisi harus menjelaskan keadaan sementara yang boleh terlihat, tindakan yang dilarang selama gap, dan siapa yang merespons saat batas terlewati.
- Tentukan sistem otoritatif serta pihak yang boleh mengoreksi nilai ketika salinan berbeda.
- Nyatakan persentase perubahan yang harus konvergen dalam batas waktu tertentu.
- Jelaskan status kepada pengguna tanpa menyatakan hasil final sebelum semua syarat terpenuhi.
- Pilih identitas dan versi yang membedakan update baru, lama, duplikat, serta konflik.
- Rancang mekanisme membandingkan jumlah, nilai, dan state antar-sistem secara berkala.
- Uji dependensi offline lebih lama daripada batas dan pastikan eskalasi memiliki pemilik.
- Tentukan apakah konflik dapat di-merge, harus mengikuti sumber, atau memerlukan keputusan manusia.
- Catat risiko bisnis ketika data belum konvergen dan larangan otomatisasi selama periode itu.
Jendela yang disepakati mengubah eventual consistency dari istilah teknis menjadi kontrak layanan. Ukur usia ketidaksamaan dan hasil rekonsiliasi, bukan hanya throughput. Bila bisnis tidak menerima state sementara, pilih desain yang memastikan keputusan selesai sebelum efek berlangsung atau ubah pengalaman pengguna agar ketidakpastian terlihat.