Sebutkan jaminan konsistensi

Pertanyaan

Saat replika bisa tertinggal, jaminan apa persisnya yang didapat pembaca, dan bagaimana kamu membuktikannya dari riwayat operasi?

Setelah baca ini, kamu bisa memeriksa sebuah riwayat baca/tulis, bilang jaminan mana yang dilanggar, dan memilih jaminan minimum yang dibutuhkan sebuah fitur.

Prasyarat dan contoh

Kamu sudah paham replikasi asinkron dan lag (M08.01).

Seorang pengguna mengganti nama tampilan dari "Sari" ke "Sari D." lewat leader. Dia menekan simpan, halaman profil dimuat ulang, dan nama lama muncul karena pembacaan jatuh ke follower yang lag 3 detik. Dia refresh lagi, kali ini kena follower yang sudah mutakhir: nama baru. Refresh ketiga, kena follower yang lag: nama lama lagi. Tidak ada data yang hilang. Yang rusak adalah pengalaman, dan "eventually consistent" tidak cukup menjelaskan kenapa.

Mekanisme

Riwayat operasi. Cara paling jelas membahas konsistensi adalah menulis operasi sebagai garis waktu per klien:

A: tulis(nama="Sari D.")  [mulai 0 ms ... selesai 10 ms]
A: baca() -> "Sari"        [mulai 12 ms ... selesai 14 ms]
A: baca() -> "Sari D."     [mulai 20 ms ... selesai 22 ms]
A: baca() -> "Sari"        [mulai 30 ms ... selesai 32 ms]

Lalu tanya: aturan mana yang dilanggar riwayat ini?

Eventual consistency. Kalau tulisan berhenti, semua replika akhirnya mengandung nilai yang sama. Itu jaminan yang sangat lemah: tidak menyebut kapan, dan tidak melarang pembaca melihat nilai lama atau nilai yang maju lalu mundur. Riwayat di atas sepenuhnya sah di bawah eventual consistency.

Read-your-writes. Klien yang menulis akan melihat tulisannya sendiri (atau yang lebih baru) pada bacaan berikutnya. Baca ke-1 ("Sari") melanggar aturan ini, karena A sudah menyelesaikan tulisannya. Cara memenuhinya: baca dari leader untuk data yang baru ditulis pengguna itu, atau bawa posisi log (token) dari tulisan terakhir dan hanya baca dari replika yang sudah melewatinya.

Monotonic reads. Klien tidak akan melihat data lebih lama dari yang pernah dia lihat. Baca ke-3 ("Sari") setelah baca ke-2 ("Sari D.") melanggarnya. Cara memenuhinya: ikat satu sesi ke satu replika (misalnya hash ID pengguna), atau lacak posisi log tertinggi yang pernah dilihat.

Linearizability. Seolah hanya ada satu salinan dan tiap operasi terjadi seketika di satu titik antara mulai dan selesai. Konsekuensi: begitu satu klien melihat nilai baru, klien lain mana pun yang memulai bacaan sesudahnya tidak boleh melihat nilai lama. Ini jaminan paling kuat dari daftar ini, dan berlaku lintas klien, bukan hanya per klien. Memenuhinya butuh koordinasi tiap operasi (konsensus, atau baca/tulis lewat leader dengan kepastian bahwa dia masih leader), jadi latensinya lebih tinggi dan ketersediaannya saat partisi lebih rendah (M08.03).

Urutan kekuatannya. Linearizability melarang semua riwayat di atas. Read-your-writes dan monotonic reads sama-sama lebih lemah dan tidak saling menjamin: riwayat bisa memenuhi satu tanpa yang lain. Eventual consistency tidak melarang satu pun. Memilih yang lebih lemah itu sah selama kamu menyebutnya, karena yang lebih kuat berbiaya latensi dan ketersediaan.

Saat rancangan ini gagal

• Memakai kata "konsisten" tanpa subjek. "Sistem kami konsisten" tidak menjawab: konsisten bagi siapa, setelah berapa lama, untuk operasi apa.
• Read-your-writes lewat sesi yang melompat replika. Token posisi log hilang saat pengguna ganti perangkat, jadi jaminannya hanya berlaku per sesi, bukan per pengguna.
• Mengira satu replika sudah linearizable. Leader lama yang belum sadar sudah digantikan masih melayani bacaan dengan nilai basi. Tanpa pengecekan kepemimpinan, bacaan dari "leader" belum linearizable.
• Memaksa linearizability di mana-mana. Hitungan tayangan dan daftar rekomendasi tidak rusak karena nilai tertinggal 2 detik. Membayar koordinasi untuk keduanya membuang kapasitas.

Contoh tandingan: transfer saldo yang membaca saldo dari follower lalu menulis hasil kurang dari saldo basis itu menghasilkan saldo salah walau tiap replika "eventually consistent". Jaminan yang dibutuhkan di sini bukan soal pembaca saja, tapi baca-lalu-tulis yang harus atomik (M05.03).

Latihan

Tiga fitur memakai database leader dengan dua follower asinkron:

1. Pengguna mengubah foto profil lalu langsung melihat halaman profilnya.
2. Feed menampilkan jumlah like, dan pengguna me-refresh beberapa kali.
3. Kasir menandai tiket konser terakhir sebagai terjual, kasir lain mengecek sisa tiket.

Untuk tiap fitur, sebut jaminan minimum dan satu cara memenuhinya.

Lihat pembahasan+

1. Read-your-writes. Pengguna cuma perlu melihat tulisannya sendiri. Cara: untuk beberapa detik setelah menulis (atau sampai replika melewati posisi log tulisan itu), arahkan bacaan profil pengguna itu ke leader.

2. Monotonic reads. Angka like boleh tertinggal, tapi tidak boleh turun dari 120 ke 118 lalu naik lagi saat refresh. Cara: ikat sesi ke satu follower, atau simpan posisi log tertinggi yang sudah dilihat dan tolak replika yang lebih tua. Linearizability di sini pemborosan.

3. Linearizability untuk tiket terakhir. Kasir kedua tidak boleh melihat "sisa 1" setelah kasir pertama menjual yang terakhir. Cara: klaim dan pengecekan lewat leader dengan operasi atomik (UPDATE ... WHERE sisa > 0) atau lewat penyimpanan berbasis konsensus. Bacaan dari follower asinkron tidak cukup.

Jawaban yang bagus menarik jaminan dari riwayat yang merusak fitur, bukan dari nama database, dan tidak memakai jaminan terkuat untuk ketiganya.

Terkait

• M08.01 Replikasikan data menjelaskan asal lag yang membuat riwayat ini mungkin terjadi.
• M08.03 Bernalar tentang partisi jaringan membahas harga ketersediaan dari jaminan yang kuat.
• M05.03 membahas pembaruan atomik untuk kasus baca-lalu-tulis, dan M05.05 membahas klaim stok yang bersamaan.

Catatan

• Asumsi: satu leader, replika asinkron, klien berinteraksi lewat sesi.
• Yang tidak dibahas: causal consistency penuh, serializability antar-transaksi, dan strong session guarantees di sistem tertentu.
• Linearizability dan serializability itu dua hal berbeda: yang pertama soal satu objek dan waktu nyata, yang kedua soal transaksi.
• Terakhir ditinjau: 26 Oktober 2026.