Pelajari mengapa basis data terdistribusi sering melonggarkan konsistensi untuk tetap tersedia saat terjadi kegagalan, bagaimana CAP dan kuorum bekerja, dan kapan memilih setiap pendekatan.
Ketika sebuah basis data dibagi ke beberapa mesin (replika), Anda mendapatkan kecepatan dan ketahanan—tetapi juga memperkenalkan periode di mana mesin‑mesin itu tidak sepenuhnya sejalan atau tidak dapat saling berbicara dengan andal.
Konsistensi berarti: setelah sebuah penulisan berhasil, semua orang membaca nilai yang sama. Jika Anda memperbarui email profil, pembacaan berikutnya—tidak peduli replika mana yang menjawab—mengembalikan email baru.
Dalam praktiknya, sistem yang memprioritaskan konsistensi mungkin menunda atau menolak beberapa permintaan saat kegagalan untuk menghindari jawaban yang bertentangan.
Ketersediaan berarti: sistem merespons setiap permintaan, bahkan jika beberapa server mati atau terputus. Anda mungkin tidak mendapatkan data terbaru, tapi Anda mendapat jawaban.
Dalam praktiknya, sistem yang memprioritaskan ketersediaan dapat menerima tulis dan melayani baca meskipun replika tidak sepakat, lalu menyeimbangkan perbedaan nanti.
Sebuah pertukaran berarti Anda tidak dapat memaksimalkan kedua tujuan sekaligus untuk setiap skenario kegagalan. Jika replika tidak dapat berkoordinasi, basis data harus:
Keseimbangan yang tepat bergantung pada kesalahan yang bisa Anda toleransi: pemadaman singkat, atau periode singkat data yang salah/kadaluwarsa. Kebanyakan sistem nyata memilih titik di tengah—dan membuat pertukaran itu eksplisit.
Sebuah basis data disebut “terdistribusi” ketika menyimpan dan melayani data dari banyak mesin (node) yang berkoordinasi melalui jaringan. Bagi aplikasi, ia mungkin masih tampak seperti satu basis data—tetapi di balik layar, permintaan dapat ditangani oleh node yang berbeda di tempat berbeda.
Kebanyakan basis data terdistribusi mereplikasi data: catatan yang sama disimpan di banyak node. Tim melakukan ini untuk:
Replikasi kuat, tapi langsung menimbulkan pertanyaan: jika dua node masing‑masing memiliki salinan data yang sama, bagaimana Anda menjamin mereka selalu setuju?
Di satu server, “mati” biasanya jelas: mesin menyala atau tidak. Di sistem terdistribusi, kegagalan sering parsial. Satu node mungkin hidup tapi lambat. Link jaringan bisa menjatuhkan paket. Sekumpulan rak bisa kehilangan konektivitas sementara klaster lain tetap berjalan.
Ini penting karena node tidak bisa seketika tahu apakah node lain benar‑benar mati, sementara tak terjangkau, atau hanya tertunda. Sambil menunggu, mereka harus memutuskan apa yang dilakukan terhadap pembacaan dan penulisan masuk.
Dengan satu server, ada satu sumber kebenaran: setiap pembacaan melihat penulisan sukses terbaru.
Dengan banyak node, “terbaru” tergantung pada koordinasi. Jika sebuah penulisan berhasil di node A tapi node B tak dapat dijangkau, apakah basis data harus:
Ketegangan itu—yang nyata karena jaringan tidak sempurna—itulah mengapa distribusi mengubah aturannya.
Sebuah partisi jaringan adalah putusnya komunikasi antara node yang seharusnya bekerja sebagai satu basis data. Node mungkin masih berjalan dan sehat, tetapi mereka tidak dapat bertukar pesan dengan andal—karena saklar yang gagal, link yang kelebihan beban, perubahan routing yang buruk, aturan firewall yang salah, atau bahkan tetangga berisik di jaringan cloud.
Setelah sistem tersebar ke banyak mesin (sering lintas rak, zona, atau region), Anda tidak lagi mengendalikan setiap hop di antara mereka. Jaringan menjatuhkan paket, memperkenalkan penundaan, dan kadang terbelah menjadi “pulau”. Pada skala kecil kejadian ini jarang; pada skala besar itu rutinitas. Bahkan gangguan singkat cukup penting, karena basis data membutuhkan koordinasi konstan untuk menyetujui apa yang terjadi.
Selama partisi, kedua sisi terus menerima permintaan. Jika pengguna dapat menulis di kedua sisi, masing‑masing dapat menerima pembaruan yang sisi lain tidak lihat.
Contoh: Node A memperbarui alamat pengguna menjadi “New Street.” Pada saat yang sama, Node B memperbarui menjadi “Old Street Apt 2.” Masing‑masing menganggap tulisannya paling baru—karena tidak ada cara untuk membandingkan catatan secara real time.
Partisi tidak muncul sebagai pesan error rapi; mereka muncul sebagai perilaku membingungkan:
Ini adalah titik tekanan yang memaksa pilihan: ketika jaringan tidak bisa menjamin komunikasi, basis data terdistribusi harus memilih memprioritaskan konsistensi atau ketersediaan.
CAP adalah cara ringkas menggambarkan apa yang terjadi saat basis data tersebar ke banyak mesin.
Saat tidak ada partisi, banyak sistem bisa tampak konsisten dan tersedia.
Saat ada partisi, Anda harus memilih apa yang diprioritaskan:
balance = 100 ke Server A.balance = 80.CAP tidak berarti “pilih dua” sebagai aturan permanen. Maksudnya saat terjadi partisi, Anda tidak bisa menjamin kedua Konsistensi dan Ketersediaan pada saat yang sama. Di luar partisi, Anda sering bisa hampir mendapat keduanya—sampai jaringan tidak berperilaku.
Memilih konsistensi berarti basis data mengutamakan “semua melihat satu kebenaran” daripada “selalu merespons”. Dalam praktiknya, ini biasanya mengarah ke konsistensi kuat, sering disebut perilaku linearizable: setelah sebuah penulisan diakui, pembacaan berikutnya (dari mana pun) mengembalikan nilai itu, seolah‑olah ada satu salinan yang selalu up‑to‑date.
Ketika jaringan terbelah dan replika tidak dapat berkomunikasi, sistem yang kuat konsistensi tidak dapat dengan aman menerima pembaruan independen di kedua sisi. Untuk melindungi kebenaran, biasanya:
Dari perspektif pengguna, ini bisa terlihat seperti pemadaman walaupun beberapa mesin masih berjalan.
Manfaat utamanya adalah penalaran yang lebih sederhana. Kode aplikasi bisa berperilaku seolah‑olah berbicara ke satu basis data, bukan beberapa replika yang mungkin berbeda. Ini mengurangi momen “aneh” seperti:
Anda juga mendapatkan model mental yang lebih bersih untuk audit, penagihan, dan hal yang harus benar pada percobaan pertama.
Konsistensi punya biaya nyata:
Jika produk Anda tidak bisa mentolerir permintaan yang gagal selama gangguan parsial, konsistensi kuat mungkin terasa mahal—meskipun itu pilihan yang tepat untuk kebenaran.
Memilih ketersediaan berarti Anda mengoptimalkan janji sederhana: sistem merespons, bahkan ketika bagian infrastruktur tidak sehat. Dalam praktiknya, “ketersediaan tinggi” bukan berarti “tidak pernah error”—itu berarti sebagian besar permintaan tetap mendapat jawaban saat node gagal, replika kewalahan, atau link jaringan putus.
Ketika jaringan terbelah, replika tidak dapat berkomunikasi dengan andal. Basis data yang memprioritaskan ketersediaan biasanya terus melayani trafik dari sisi yang dapat dijangkau:
Ini menjaga aplikasi tetap berjalan, tetapi berarti replika berbeda mungkin sementara menerima kebenaran berbeda.
Anda mendapatkan uptime lebih baik: pengguna masih bisa menelusuri, menambah item ke keranjang, mengirim komentar, atau merekam event walau sebuah region terisolasi.
Anda juga mendapatkan pengalaman pengguna yang lebih mulus saat tekanan. Daripada timeout, aplikasi dapat terus berfungsi (“pembaruan Anda tersimpan”) dan menyinkronkan kemudian. Untuk banyak beban kerja konsumer dan analitik, pertukaran itu sepadan.
Harganya adalah basis data dapat mengembalikan bacaan usang. Pengguna mungkin memperbarui profil di satu replika, lalu segera membaca dari replika lain dan melihat nilai lama.
Anda juga berisiko konflik tulis. Dua pengguna (atau satu pengguna dari dua lokasi) dapat memperbarui rekaman yang sama di sisi partisi yang berbeda. Saat partisi sembuh, sistem harus merekonsiliasi riwayat yang berbeda. Bergantung aturan, satu tulis bisa “menang”, field bisa digabung, atau konflik mungkin memerlukan logika aplikasi.
Desain berfokus ketersediaan menerima ketidaksepakatan sementara agar produk tetap merespons—lalu menginvestasikan cara mendeteksi dan memperbaiki perbedaan itu nanti.
Kuorum adalah teknik “voting” praktis yang dipakai banyak basis data terreplikasi untuk menyeimbangkan konsistensi dan ketersediaan. Alih‑alih mempercayai satu replika, sistem meminta cukup replika untuk setuju.
Anda sering melihat kuorum dengan tiga angka:
Aturan praktis: jika R + W > N, maka setiap pembacaan tumpang tindih dengan penulisan sukses terbaru pada setidaknya satu replika, yang mengurangi kemungkinan membaca data usang.
Jika Anda punya N=3 replika:
Beberapa sistem memilih W=3 (semua replika) untuk konsistensi lebih kuat, tetapi itu bisa menyebabkan lebih banyak kegagalan tulis saat ada replika lambat atau mati.
Kuorum tidak menghilangkan masalah partisi—mereka menentukan siapa yang diperbolehkan membuat kemajuan. Jika jaringan terbelah 2–1, sisi yang punya 2 replika masih bisa memenuhi R=2 dan W=2, sementara replika terisolasi tunggal tidak bisa. Itu mengurangi pembaruan yang bertentangan, tetapi berarti beberapa klien akan melihat error atau timeout.
Kuorum biasanya berarti latensi lebih tinggi (lebih banyak node untuk dihubungi), biaya lebih tinggi (lalu lintas antar‑node), dan perilaku kegagalan yang lebih rumit (timeout terlihat seperti ketidaktersediaan). Keuntungannya adalah jalan tengah yang dapat disetel: Anda dapat memutar R dan W ke arah pembacaan lebih segar atau keberhasilan tulis lebih tinggi tergantung kebutuhan.
Konsistensi akhirnya berarti replika diperbolehkan sementara tidak sinkron, asalkan mereka konvergen ke nilai yang sama nanti.
Bayangkan rantai kedai kopi memperbarui papan “sold out” kue. Satu toko menandai habis, tapi pembaruan itu sampai ke toko lain beberapa menit kemudian. Selama jendela itu, toko lain mungkin masih menampilkan “tersedia” dan menjual yang terakhir. Sistem tidak “rusak”—pembaruan hanya sedang mengejar.
Saat data masih menyebar, klien dapat mengamati perilaku yang terasa mengejutkan:
Sistem eventual consistency biasanya menambahkan mekanisme latar belakang untuk mengurangi jendela inkonsistensi:
Cocok ketika ketersediaan lebih penting daripada kerapian waktu: feed aktivitas, penghitung view, rekomendasi, cache profil, log/telemetri, dan data non‑kritis lain yang “benar dalam beberapa saat” dapat diterima.
Saat basis data menerima tulis di banyak replika, ia bisa berakhir dengan konflik: dua (atau lebih) pembaruan pada item yang sama yang terjadi secara independen pada replika berbeda sebelum sinkronisasi.
Contoh klasik: pengguna mengubah alamat pengiriman di satu perangkat sambil mengubah nomor telepon di perangkat lain. Jika masing‑masing update mendarat pada replika berbeda selama pemutusan sementara, sistem harus menentukan apa yang menjadi rekaman “sebenarnya” saat replika bertukar data lagi.
Banyak sistem memulai dengan last‑write‑wins: pembaruan dengan cap waktu terbaru menimpa yang lain.
Sederhana dan cepat, tetapi bisa menghilangkan data tanpa terlihat. Jika “terbaru” menang, maka perubahan lama yang penting bisa terhapus—bahkan jika kedua pembaruan menyentuh field berbeda.
Ini juga mengasumsikan jam dapat dipercaya. Perbedaan jam antar mesin (clock skew) dapat membuat pembaruan yang “salah” menang.
Penanganan konflik yang lebih aman biasanya membutuhkan pelacakan sejarah kausal. Pada tingkat konseptual, version vectors (dan varian lebih sederhana) melampirkan metadata kecil pada setiap rekaman yang merangkum “replika mana yang telah melihat pembaruan mana.” Saat replika bertukar versi, basis data dapat mendeteksi apakah satu versi menyertakan yang lain (tidak ada konflik) atau apakah mereka menyimpang (konflik yang perlu resolusi).
Beberapa sistem memakai timestamp logis (mis. Lamport clocks) atau jam logis hibrida untuk mengurangi ketergantungan pada jam dinding sambil tetap memberi petunjuk pengurutan.
Saat konflik terdeteksi, Anda punya pilihan:
Pendekatan terbaik bergantung pada apa arti “benar” untuk data Anda—kadang kehilangan tulis dapat diterima, dan kadang itu bug bisnis‑kritis.
Memilih sikap konsistensi/ketersediaan bukan debat filosofis—itu keputusan produk. Mulailah dengan menanyakan: berapa biaya jika salah untuk sesaat, dan berapa biaya mengatakan "coba lagi nanti"?
Beberapa domain butuh jawaban tunggal berwenang saat menulis karena “hampir benar” tetap salah:
Jika dampak ketidaksesuaian sementara rendah atau bisa dibalik, Anda biasanya bisa condong ke ketersediaan.
Banyak pengalaman pengguna baik‑baik saja dengan pembacaan sedikit lama:
Jadilah eksplisit tentang seberapa usang yang boleh: detik, menit, atau jam. Anggaran waktu itu mengarahkan pilihan replikasi dan kuorum Anda.
Saat replika tidak sepakat, Anda biasanya berakhir dengan salah satu dari tiga hasil UX:
Pilih opsi yang paling sedikit merusak per fitur, bukan secara global.
Condong ke C (konsistensi) jika: hasil yang salah menimbulkan risiko finansial/legal, isu keamanan, atau tindakan yang tidak dapat dibalik.
Condong ke A (ketersediaan) jika: pengguna menghargai responsif, data usang dapat ditoleransi, dan konflik bisa diselesaikan dengan aman nanti.
Jika ragu, pisahkan sistem: jaga rekaman kritis dengan konsistensi kuat, dan biarkan tampilan turunan (feed, cache, analitik) mengoptimalkan ketersediaan.
Jarang Anda harus memilih satu “pengaturan konsistensi” untuk seluruh sistem. Banyak basis data modern membiarkan Anda memilih konsistensi per operasi—dan aplikasi pintar memanfaatkan itu untuk menjaga pengalaman pengguna lancar tanpa berpura‑pura pertukaran tidak ada.
Perlakukan konsistensi seperti kenop yang Anda putar berdasarkan apa yang pengguna lakukan:
Ini menghindari membayar biaya konsistensi terkuat untuk segala hal, sambil tetap melindungi operasi yang benar‑benar membutuhkannya.
Pol yang umum adalah kuat untuk tulis, lebih lemah untuk baca:
Dalam beberapa kasus, sebaliknya bekerja: tulis cepat (queued/eventual) ditambah baca kuat saat mengonfirmasi hasil (“Apakah pesanan saya terpasang?”).
Saat jaringan goyah, klien retry. Buat retry aman dengan idempotency keys sehingga “kirim pesanan” yang dieksekusi dua kali tidak membuat dua pesanan. Simpan dan gunakan kembali hasil pertama saat kunci yang sama muncul lagi.
Untuk aksi multi‑langkah di banyak layanan, gunakan saga: setiap langkah punya aksi kompensasi (refund, lepas reservasi, batalkan pengiriman). Ini membuat sistem dapat dipulihkan meski bagian‑bagian sementara tidak sepakat atau gagal.
Anda tidak bisa mengelola pertukaran konsistensi/ketersediaan jika Anda tidak bisa melihatnya. Masalah produksi sering terlihat seperti “kegagalan acak” sampai Anda menambahkan pengukuran dan tes yang tepat.
Mulailah dengan set kecil metrik yang berkaitan langsung ke dampak pengguna:
Jika bisa, tag metrik menurut mode konsistensi (quorum vs lokal) dan region/zone untuk menemukan tempat perilaku menyimpang.
Jangan tunggu pemadaman nyata. Di staging, jalankan eksperimen chaos yang mensimulasikan:
Verifikasi bukan hanya “sistem tetap hidup,” tapi jaminan apa yang bertahan: apakah baca tetap segar, apakah tulis terblokir, apakah klien mendapat error yang jelas?
Tambahkan alert untuk:
Terakhir, buat janji eksplisit: dokumentasikan apa yang sistem Anda janjikan saat operasi normal dan saat partisi, dan edukasikan tim produk serta support tentang apa yang mungkin dilihat pengguna dan bagaimana merespons.
Jika Anda mengeksplorasi pertukaran ini dalam produk baru, berguna memvalidasi asumsi lebih awal—terutama mode kegagalan, perilaku retry, dan seperti apa “usang” di UI.
Satu pendekatan praktis adalah mem‑prototype versi kecil alur kerja (path tulis, path baca, retry/idempotensi, dan job rekonsiliasi) sebelum komit ke arsitektur penuh. Dengan layanan prototyping seperti Koder.ai, tim dapat cepat menyiapkan web app dan backend lewat alur kerja berbasis chat, mengiterasi model data dan API, serta menguji pola konsistensi berbeda (mis. tulis ketat + baca santai) tanpa overhead pipeline build tradisional. Saat prototipe cocok dengan perilaku yang diinginkan, Anda bisa mengekspor kode sumber dan mengembangkannya menjadi produksi.
Pada basis data yang direplikasi, “data yang sama” tersimpan di beberapa mesin. Itu meningkatkan ketahanan dan bisa menurunkan latensi, tetapi memperkenalkan masalah koordinasi: node bisa lambat, tak terjangkau, atau terpisah oleh jaringan, sehingga mereka tidak selalu bisa langsung sepakat pada penulisan terbaru.
Konsistensi berarti: setelah sebuah penulisan berhasil, setiap pembacaan berikutnya mengembalikan nilai yang sama—tidak peduli replika mana yang melayani. Dalam praktiknya, sistem sering menegakkan ini dengan menunda atau menolak pembacaan/penulisan sampai cukup replika (atau pemimpin) mengonfirmasi pembaruan.
Ketersediaan berarti sistem mengembalikan respons non-error untuk setiap permintaan, bahkan saat beberapa node mati atau tidak bisa berkomunikasi. Respons itu bisa kedaluwarsa, parsial, atau berdasarkan pengetahuan lokal, tetapi sistem menghindari memblokir pengguna selama kegagalan.
Partisi jaringan adalah putusnya komunikasi antar node yang seharusnya bertindak sebagai satu sistem. Node mungkin masih sehat, tetapi pesan tidak dapat melintasi pemisahan dengan andal, sehingga memaksa basis data memilih antara:
Selama partisi, kedua sisi bisa menerima pembaruan yang tidak bisa segera dibagikan. Itu dapat menyebabkan:
Ini adalah hasil yang terlihat pengguna ketika replika sementara tidak bisa berkoordinasi.
Bukan berarti “pilih dua selamanya.” Maksudnya: saat terjadi partisi, Anda tidak dapat menjamin kedua hal sekaligus:
Di luar partisi, banyak sistem tampak menawarkan keduanya sebagian besar waktu—sampai jaringan bermasalah.
Kuorum menggunakan pemungutan suara antar replika:
Panduan umum: R + W > N untuk mengurangi kemungkinan membaca data usang. Kuorum tidak menghilangkan partisi; mereka menentukan siapa yang diizinkan melanjutkan progres (misalnya sisi yang masih punya mayoritas).
Konsistensi akhirnya (eventual consistency) membolehkan replika sementara tidak sinkron selama mereka konvergen ke nilai yang sama nanti. Anomali umum meliputi:
Sistem biasanya mengurangi jendela inkonsistensi dengan , , dan rekonsiliasi berkala (anti‑entropy).
Konflik terjadi ketika replika berbeda menerima tulis berbeda pada item yang sama saat terputus. Strategi penyelesaian meliputi:
Pilih strategi berdasarkan apa yang berarti “benar” untuk data Anda.
Tentukan berdasarkan risiko bisnis dan mode kegagalan yang dapat ditoleransi pengguna Anda:
Polanya termasuk tingkat konsistensi per‑operasi, retry aman dengan idempotency keys, dan dengan kompensasi untuk alur multi‑langkah.