Prompt dan Peran yang Berlaku
Sistem komentar dengan replikasi geografis (geo-replicated) menyimpan komentar induk dan balasannya pada replika yang berbeda. Pengguna tidak boleh melihat balasan lalu kemudian kehilangan komentar induknya, atau membaca versi yang lebih lama setelah penulisan berhasil. Jelaskan causal consistency versus linearizability dan eventual consistency, rancang jaminan sesi (session guarantees), dan tunjukkan cara memverifikasi bahwa implementasi tersebut tidak mengalami causal inversion.
Pertanyaan ini cocok untuk wawancara distributed systems, backend, infrastruktur, dan rekayasa perangkat lunak umum. Pertanyaan ini tidak memerlukan basis data tertentu. Jelaskan model replika, replication lag, dan fakta bahwa permintaan membawa konteks kausal yang dapat dipropagasikan.
Hal yang Diuji oleh Pewawancara
Jawaban yang kuat memiliki empat lapisan: mendefinisikan happens-before dan membedakan tingkat kekuatan konsistensi; memetakan read-your-writes, monotonic reads, monotonic writes, dan writes-follow-reads ke dalam alur permintaan; menjelaskan bagaimana replika menunggu atau meneruskan permintaan untuk memenuhi dependensi; serta menggunakan delayed replication, reordered messages, dan failover untuk membuktikan properti-properti tersebut. Jawaban tersebut juga harus menyatakan bahwa causal consistency tidak menciptakan total order untuk penulisan konkuren; resolusi konflik tetap menjadi urusan tingkat aplikasi.
Pertanyaan Klarifikasi Sebelum Menjawab
Hubungan "terkait secara kausal" biasanya berasal dari operasi tulis yang diikuti oleh operasi baca dalam satu sesi klien, operasi tulis yang membaca hasil dari operasi tulis lain, atau hubungan induk-anak yang eksplisit dalam domain. Penulisan konkuren tanpa edge happens-before dapat muncul dalam urutan yang berbeda di replika yang berbeda. Jangan mendefinisikan causal consistency sebagai setiap klien melihat satu urutan yang identik.
Klarifikasi empat batasan: apakah konteks melintasi mekanisme retry dan antrean asinkron; apakah replika boleh tertinggal secara permanen; seberapa basi (stale) data bacaan yang diperbolehkan; dan apakah penanganan konflik menggunakan LWW, CRDT, atau aturan domain. Tanpa batasan ini, jaminan yang diklaim tidak dapat diuji.
Kerangka Jawaban 30 Detik
“Causal consistency mengharuskan penulisan yang terkait secara kausal untuk diamati dalam urutan kausal yang sama, sementara penulisan konkuren dapat muncul dalam urutan yang berbeda. Model ini memberikan jaminan yang terlihat oleh pengguna yang lebih kuat daripada eventual consistency, tetapi bukan merupakan linearizability atau external consistency milik Spanner; model-model yang lebih kuat tersebut juga mengharuskan hasil sesuai dengan satu urutan real-time.
Saya akan mempropagasi version vector atau token kausal buram (opaque) dari klien. Setiap operasi tulis mengirimkan dependensi yang diketahuinya ke replika dan menggabungkan kembali versi yang sudah di-commit ke dalam token. Operasi baca hanya diarahkan ke replika yang telah memenuhi token tersebut, atau menunggu atau meneruskannya; jika tidak dapat memenuhi kontrak, sistem mengembalikan hasil yang secara eksplisit mengalami degradasi (degraded). Saya akan menginjeksikan latensi replikasi, pengurutan ulang pesan, retry, dan failover, lalu memastikan bahwa balasan tidak pernah muncul tanpa induknya dan sesi tidak pernah kehilangan penulisannya sendiri sambil mengukur latensi tunggu, ukuran konteks, dan tingkat fallback.”
Pembahasan Mendalam Langkah demi Langkah
Konteks Dependensi dan Desain Jaminan Sesi
Representasikan konteks klien sebagai version vector atau token kausal buram (opaque). Replika melacak versi yang telah diterapkannya dan memeriksa dependensi sebelum melayani operasi baca:
context = client.context
write(key, value, context):
result = replica.write(key, value, dependency=context)
context = merge(context, result.version)
return result
read(key, context):
replica = chooseReplicaSatisfying(context)
result = replica.readAfter(context)
context = merge(context, result.context)
return resultRead-your-writes berarti operasi baca setelahnya tidak lebih lama dari penulisan yang dilakukan oleh sesi itu sendiri. Monotonic reads berarti sesi tidak pernah mengalami kemunduran urutan waktu. Monotonic writes berarti penulisan dari satu sesi diterapkan sesuai urutan commit. Writes-follow-reads berarti penulisan berikutnya membawa dependensi yang telah diamati oleh operasi baca sebelumnya. Jika sebuah replika kekurangan dependensi, ia dapat menunggu, meneruskannya ke replika dengan safe point yang lebih baru, atau mengembalikan hasil stale yang ditandai sebagai degraded jika produk secara eksplisit mengizinkannya. Opsi terakhir tidak dapat lagi mengklaim jaminan aslinya.
Penulisan Konkuren, Kegagalan, dan Trade-off Performa
Causal consistency hanya membatasi pengurutan yang dapat diturunkan secara kausal. Jika dua pengguna mengedit teks yang sama secara bersamaan, model ini tidak memilih pemenang untuk aplikasi. LWW dapat menghilangkan pembaruan; CRDT atau domain merges dapat mempertahankan lebih banyak maksud (intent), dengan konsekuensi biaya metadata dan implementasi.
Konteks yang lebih presisi dapat meningkatkan waktu tunggu dependensi dan tail latency, serta version vectors dapat membengkak. Mengirim setiap permintaan ke primary menyederhanakan jaminan tetapi mengorbankan latensi regional dan ketersediaan (availability). Replikasi eventual consistency lebih murah, tetapi tidak secara otomatis menyediakan read-your-writes atau monotonic reads. Jika bisnis mengharuskan urutan commit cocok dengan urutan real-time, evaluasi linearizability atau external consistency dengan menerima konsekuensi koordinasi yang lebih tinggi.
Rencana Verifikasi yang Dapat Dieksekusi
Bangun pengujian dengan rantai kausal yang unik: tulis komentar induk, baca komentar tersebut, tulis balasannya, dan baca dari replika di berbagai wilayah. Injeksikan latensi replikasi, partisi jaringan, pesan yang diurutkan ulang dan diduplikasi, retry pada klien, serta failover pada primary. Catat token kausal, versi yang diamati, dan ID replika untuk setiap operasi baca.
Pastikan setidaknya bahwa permintaan yang mengamati balasan juga dapat mengamati induknya; penulisan yang berhasil tidak diikuti oleh pembacaan versi yang lebih lama dalam sesi yang sama; versi bacaan sesi bersifat monoton; dan penulisan konkuren dapat diamati dalam urutan berbeda namun pada akhirnya konvergen di bawah aturan konflik yang dideklarasikan. Simpan urutan peristiwa pelanggaran terpendek sehingga Anda dapat membedakan antara hilangnya token, pemeriksaan dependensi yang salah, dan watermark replika yang stale.
Contoh Jawaban Berkualitas Tinggi
“Saya akan mendefinisikan edge dari induk ke balasan sebagai happens-before. Causal consistency mengharuskan setiap replika untuk mempertahankan edge tersebut, sementara dua komentar yang dibuat secara bersamaan dapat muncul dalam urutan berbeda. Linearizability juga memerlukan satu urutan real-time; eventual consistency hanya menjanjikan konvergensi setelah proses penulisan berhenti.
Klien mempertahankan version vector atau token kausal dan mempropagasikannya melalui retry, tugas asinkron, dan pemanggilan layanan. Operasi tulis mengirimkan token sebagai dependensi dan menggabungkan versi barunya saat berhasil. Operasi baca memilih replika yang telah memenuhi token tersebut, atau menunggu atau meneruskannya. Ini mengimplementasikan read-your-writes, monotonic reads, monotonic writes, dan writes-follow-reads, yang tunduk pada semantik tunggu dan fallback yang eksplisit.
Saya tidak akan mengklaim bahwa causal consistency menyelesaikan konflik konkuren. Bidang yang sama masih membutuhkan LWW, CRDT, atau domain merge. Pengujian akan menunda dan mengurutkan ulang replikasi, menduplikasi permintaan, dan melakukan failover antar replika, untuk memastikan balasan tidak pernah terpisah dari induknya, versi sesi tidak pernah mundur, serta tail latency, ukuran konteks, waktu tunggu, dan tingkat fallback tetap berada dalam batas yang ditentukan.”
Kesalahan Umum
- Menyebut causal consistency sebagai global total order → penulisan konkuren tidak memiliki urutan wajib → pisahkan happens-before dari konkurensi.
- Mengatakan "replika pada akhirnya akan sinkron" → hal itu tidak memberikan jaminan sesi apa pun → jelaskan token, pemeriksaan dependensi, dan pemilihan replika.
- Mengasumsikan read-your-writes adalah bawaan database → perutean lintas replika dapat mengembalikan versi yang lebih lama → propagasikan versi penulisan dan periksa watermark replika.
- Kehilangan konteks dalam antrean asinkron → tugas pemrosesan balasan kehilangan dependensi induknya → bawa token di dalam pesan dan metadata retry.
- Mengklaim LWW menyelesaikan konflik kausal → LWW dapat menimpa pembaruan konkuren → jadikan kebijakan penggabungan sebagai keputusan aplikasi yang terpisah.
- Hanya menguji jalur normal (healthy path) → latensi, pengurutan ulang, dan failover dapat mengungkap inversi kausal → injeksikan gangguan (fault injection) dan simpan urutan peristiwa terpendek.
Pertanyaan Lanjutan dan Tanggapan
Pertanyaan Lanjutan 1: Kapan Anda memilih causal consistency daripada linearizability?
Pilih linearizability atau semantik yang lebih kuat ketika setiap klien harus mengamati satu urutan real-time dan operasi harus tampak atomik seolah-olah berada pada satu mesin. Timeline komentar sering kali hanya memerlukan visibilitas induk-anak dan jaminan sesi, sehingga causal consistency dapat mempertahankan kinerja pembacaan lokal yang lebih baik. Saldo pembayaran harus terlebih dahulu memenuhi invariant bisnisnya sebelum memilih biaya koordinasi.
Pertanyaan Lanjutan 2: Bisakah sebuah replika mengembalikan pembacaan stale saat kekurangan dependensi?
Hanya jika API menandainya sebagai degraded dan pemanggil menerima kontrak tersebut. Jika produk menjanjikan bahwa melihat balasan berarti melihat induknya, pembacaan stale melanggar kontrak; lakukan tunggu, teruskan, atau kembalikan error yang dapat dicoba lagi (retryable) dan sertakan batas waktu tunggu dalam SLO.
Pertanyaan Lanjutan 3: Bisakah version vectors membengkak tanpa batas?
Replika dan klien yang lebih banyak akan meningkatkan ukuran metadata. Kompresi token, leases, causal stability points, atau kumpulan partisipan yang dibatasi dapat mengendalikan biaya, tetapi setiap teknik harus membuktikan bahwa dependensi yang diperlukan tidak terhapus. Ukur ukuran konteks dan overhead penggabungan di bawah churn keanggotaan yang diperkirakan.
Pertanyaan Lanjutan 4: Bagaimana Anda membuktikan pengujian mencakup causal inversion yang sebenarnya?
Catat ID tulis, token dependensi, watermark yang diterapkan, replika, dan hasil baca untuk setiap peristiwa, lalu bangun graf happens-before. Jalankan ulang rantai pelanggaran terpendek dan pastikan jalur hilangnya token, pengiriman duplikat, pengurutan ulang, dan failover dapat mereproduksi kegagalan tersebut atau memicu assertion.