Topik wawancara representatif

Wawancara umum: Bagaimana Anda menjelaskan CAP dan membuat trade-off konsistensi?

UmumSedang
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Jelaskan CAP dan tentukan apakah sistem pesanan lintas wilayah harus mengutamakan konsistensi atau ketersediaan selama partisi jaringan. Definisikan istilah-istilahnya terlebih dahulu, lalu bahas trade-off, perilaku pengguna, pemulihan, dan validasi.

Petunjuk dan konteks

Sebuah sistem memiliki beberapa node yang menyimpan data bisnis yang sama, dan node-node tersebut dapat terpartisi. Jelaskan Konsistensi (Consistency), Ketersediaan (Availability), dan Toleransi Partisi (Partition tolerance), lalu terapkan pada pesanan, inventaris, atau feed media sosial. Jangan berhenti pada "pilih dua"; jelaskan apa yang dilihat pengguna, penulisan mana yang diterima, dan bagaimana sistem melakukan konvergensi setelah pemulihan.

Apa yang diuji oleh pewawancara

Pewawancara ingin Anda menempatkan trade-off selama partisi, mendefinisikan konsistensi sebagai jaminan pembacaan dan ketersediaan sebagai jaminan respons yang tepat waktu, serta memperlakukan toleransi partisi sebagai batasan jaringan terdistribusi yang nyata. Jawaban yang kuat menghubungkan risiko bisnis, degradasi, penanganan konflik, observabilitas, dan pemulihan alih-alih menggantikan penalaran dengan sekadar label basis data.

Pertanyaan untuk diklarifikasi

  • Apakah konsistensi bersifat linearizable, tingkat sesi, atau boleh sedikit basi (stale)?
  • Apakah ketersediaan memperbolehkan kesalahan eksplisit yang dapat dicoba kembali (retryable)?
  • Operasi mana yang harus dihentikan selama partisi, seperti pembayaran, inventaris, atau pembatalan?
  • Apakah antrean lokal, percobaan ulang idempoten, penggabungan konflik, atau peninjauan manual diizinkan?
  • Apakah tujuan pemulihan adalah nol kehilangan data, konvergensi monotonik, atau jendela kompensasi yang terbatas?

Jawaban 30 detik

CAP menyatakan bahwa selama partisi jaringan, sebuah sistem tidak dapat menjamin konsistensi kuat sekaligus respons yang tersedia untuk setiap permintaan; P adalah batasan untuk terus berjalan melewati partisi. Saya akan mengklasifikasikan kesalahan bisnis yang tidak dapat diterima terlebih dahulu: pembayaran dan inventaris dapat mengembalikan kesalahan yang dapat dicoba kembali, sementara feed media sosial dapat menyajikan data yang basi. Kemudian saya akan menjelaskan idempotensi, log konflik, pemutaran ulang (replay), pemulihan, dan metrik alih-alih mengklaim bahwa basis data secara permanen "merupakan CP sekaligus AP".

Jawaban mendalam langkah demi langkah

Langkah 1: Definisikan ketiga istilah tersebut

Konsistensi adalah jaminan pembacaan; konsistensi kuat umumnya digambarkan sebagai membaca data penulisan terakhir yang telah selesai. Ketersediaan berarti setiap permintaan menerima respons dalam kontrak sistem. Toleransi partisi berarti sistem dapat menangani komunikasi antar-node yang hilang atau tertunda tanpa batas. Kasus penentu CAP adalah saat P terjadi.

Langkah 2: Buat garis waktu partisi

Asumsikan Tokyo dan Singapura tidak dapat berkomunikasi. Jika keduanya menerima penulisan yang berlawanan untuk satu akun dan segera merespons, konflik dapat terjadi dan konsistensi kuat hilang. Jika hanya satu sisi yang menulis atau keduanya menolak operasi yang tidak pasti, sebagian ketersediaan dikorbankan. Gambarkan garis waktu sebelum menyebutkan penyimpanan data.

Langkah 3: Pilih perilaku berdasarkan risiko bisnis

Inventaris, otorisasi pembayaran, dan nama unik harus menghindari penulisan ganda; selama partisi, proses tersebut dapat mengembalikan status yang dapat dicoba kembali atau mengantrekan pekerjaan. Suka (likes), jumlah tayangan, dan rekomendasi sering kali dapat mentoleransi pembacaan data yang basi dan penggabungan asinkron. Pilihan ini mengikuti biaya dari suatu kesalahan, bukan slogan AP/CP.

text
partitioned:
  if operation == payment_or_inventory:
    reject_or_queue_with_idempotency_key()
  else:
    serve_stale_read_and_record_reconciliation()

Langkah 4: Tentukan penulisan dan konflik

Penulisan yang dapat dicoba kembali membawa kunci idempotensi dan versi. Penulisan multi-wilayah mencatat asal, waktu logis, dan bukti; pemulihan menggabungkan, mengompensasi, atau mengirimkan konflik ke peninjauan sesuai dengan aturan bisnis. Last-write-wins tidak boleh menyembunyikan konflik pembayaran atau inventaris yang tidak dapat diubah kembali (irreversible).

Langkah 5: Jelaskan pemulihan

Setelah komunikasi pulih, pertukarkan log dan versi, deteksi celah data serta duplikasi, dan putar ulang kejadian yang dapat dicoba kembali secara berurutan. Berikan pesanan yang belum terselesaikan status eksplisit agar pengguna tidak membayar dua kali. Terapkan pembatasan laju (rate-limit) pada pemulihan dan gunakan antrean dead-letter serta antrean manual untuk rekaman yang bermasalah.

Langkah 6: Hubungkan ke validasi

Lacak durasi partisi, tingkat penolakan, usia pembacaan data yang basi, jumlah konflik, keberhasilan kompensasi, dan permintaan duplikat. Injeksikan kegagalan pada pembacaan, penulisan, percobaan ulang, pemulihan, dan latensi lintas wilayah, lalu verifikasi bahwa pesan pengguna sesuai dengan status sebenarnya.

Trade-off dan batasan

CAP bukanlah label basis data dua huruf yang permanen

Pilihan ini merupakan perilaku selama terjadinya partisi; di luar itu, latensi, biaya, durabilitas, dan operasional tetap penting. Menyebut sistem sebagai "AP" atau "CP" tanpa jaminan tingkat permintaan hanya akan mengaburkan desain sebenarnya.

Nyatakan tingkat kekuatan konsistensi

"Konsisten" dapat berarti linearizable, kausal, sesi, atau konvergensi eventual. Definisikan kontrak baca dan tulis sebelum mendiskusikan node dan protokol.

Rencana peluncuran dan bukti

Petakan persyaratan ke kebijakan

Untuk pembayaran, inventaris, status pesanan, pencarian, dan penghitung sosial, tuliskan perilaku saat partisi, teks untuk pengguna, batasan percobaan ulang, dan tindakan pemulihan. Petakan setiap janji ke API dan model data.

Jalankan latihan simulasi kegagalan

Latih kondisi kehilangan data satu arah, penundaan, pesan duplikat, dan pemulihan parsial. Periksa respons akhir, rekaman idempotensi, antrean konflik, akuntansi kompensasi, dan peringatan; bersihkan data uji coba dan tinjau log audit setelahnya.

Kesalahan umum dan tindak lanjut

Kesalahan: mengklaim CA dapat bertahan dari partisi

CA menggambarkan konsistensi dan ketersediaan ketika partisi ditiadakan; sistem lintas-node yang nyata harus mampu menangani kegagalan komunikasi.

Kesalahan: menyamakan ketersediaan dengan selalu berhasil

Ketersediaan adalah jaminan respons yang tepat waktu. Kesalahan, antrean, atau percobaan ulang eksplisit dapat menjadi perilaku bisnis yang benar jika kontraknya jelas.

Kesalahan: menimpa setiap konflik dengan last-write-wins

Konflik pembayaran dan inventaris memerlukan idempotensi, versi, kompensasi, atau peninjauan; penimpaan secara membabi buta akan menghilangkan fakta bisnis.

Tindak lanjut: mengapa P biasanya tidak dapat dihindari?

Jaringan lintas wilayah dapat terpartisi atau mengalami penundaan yang tidak dapat diterima; melepaskan P berarti menghentikan layanan terdistribusi saat komunikasi gagal.

Tindak lanjut: bagaimana Anda membuktikan pilihan tersebut?

Tunjukkan latihan simulasi partisi, status yang terlihat oleh pengguna, metrik konflik dan kompensasi, serta kondisi rollback untuk kebijakan tersebut.

Sumber publik

Pertanyaan terkait