Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.
Apa isi teorema CAP sebenarnya, kenapa partition memaksa kita memilih, apa tambahan PACELC, dan bagaimana PostgreSQL, MongoDB dan Redis menyikapinya.
Matthews Wong
Software Engineer
Ringkasan Utama
Teorema CAP menyatakan bahwa ketika network partition memecah database terdistribusi, sistem harus memilih antara consistency (read selalu melihat write terbaru) dan availability (setiap request mendapat jawaban). Partition tidak bisa dihindari, sehingga database condong ke CP atau AP. PACELC menambahkan bahwa tanpa partition pun, consistency tetap dipertukarkan dengan latency.
Bayangkan tablet kasir di POS carwash yang kehilangan Wi-Fi di tengah shift, sementara pelanggan berdiri di depan kasir. Pertanyaannya tiba-tiba konkret: apakah tablet menolak transaksi, atau menerimanya lalu direkonsiliasi nanti? Saya membangun sistem ERP dan POS, dan inilah wujud CAP yang paling sering saya temui.
Itulah seluruh teorema dalam satu adegan. Artikel ini menjawab pertanyaan yang benar-benar dicari orang, yaitu apa itu CAP dan bagaimana pengaruhnya pada pilihan database, memakai hitungan contoh dan dokumentasi resmi PostgreSQL, MongoDB dan Redis. Setiap perilaku yang disebut di bawah merujuk ke dokumentasi tersebut atau ke referensi CAP dan PACELC di akhir.
CAP menjelaskan tiga properti dari data store terdistribusi, dan definisi yang tepat itu penting karena kebingungan biasanya berasal dari definisi yang longgar.
Teorema ini, yang digagas Eric Brewer dan dibuktikan oleh Gilbert dan Lynch, menyatakan bahwa sistem tidak bisa menjamin ketiganya sekaligus. Bagian yang sering terlupa adalah syaratnya: batasan itu baru berlaku saat partition sedang terjadi.
Tidak dalam praktik. Di jaringan nyata kita tidak bisa memilih untuk bebas dari partition, jadi partition tolerance bukan menu pilihan. Cara pandang yang jujur: saat partition terjadi, kita memilih consistency atau availability, dan saat jaringan sehat keduanya bisa didapat.
Hasilnya ada dua perilaku. Sistem CP menolak atau menunda sebagian request selama partition supaya tidak mengembalikan data basi atau konflik. Sistem AP tetap menjawab di kedua sisi lalu merekonsiliasi perbedaannya kemudian. Tidak ada yang lebih baik; keduanya jawaban untuk pertanyaan berbeda tentang biaya jawaban yang salah.
Tanyakan dulu pertanyaan bisnisnya: apakah request yang ditolak lebih buruk daripada jawaban yang basi? Untuk ledger pembayaran, penolakan biasanya lebih murah. Untuk halaman katalog produk, harga yang sedikit lama lebih baik daripada halaman error.
Ambil cluster 3 node yang butuh mayoritas untuk menerima write. Seluruh hitungan di bawah diturunkan, tanpa pengukuran. Hitungan ini menunjukkan kenapa ukuran cluster ganjil jadi norma dan bagaimana ukuran read dan write quorum menentukan read yang konsisten atau yang available.
// Majority quorum: the smallest group that two partitions cannot both form.
const quorum = (n: number) => Math.floor(n / 2) + 1;
quorum(3); // 2 -> a 3-node cluster survives 1 node down
quorum(5); // 3 -> a 5-node cluster survives 2 nodes down
quorum(4); // 3 -> 4 nodes still survive only 1 down; the 4th node buys nothing
// Read-your-writes holds when the read set and write set must overlap:
// W + R > N
// N = 3, W = 2, R = 2 -> 4 > 3 overlap guaranteed (consistent reads)
// N = 3, W = 1, R = 1 -> 2 > 3 false, a read can miss the latest write (fast, available)
// A 3-node cluster splits 2 | 1:
// side with 2 nodes: can reach quorum(3) = 2 -> accepts writes
// side with 1 node : cannot reach quorum -> must refuse (CP) or diverge (AP)Pecahan 2 lawan 1 adalah kasus yang berguna. Sisi dengan dua node masih memegang mayoritas, jadi tetap menerima write. Sisi dengan satu node tidak bisa, sehingga desain CP membuatnya menolak, sedangkan desain AP membiarkannya menerima write yang akan konflik nanti. Penolakan di sisi minoritas itulah harga availability dari huruf C pada CAP.
PACELC, yang diusulkan Daniel Abadi, memperluas gagasan ini: jika ada partition (P), pilih availability atau consistency (A atau C); else (E), saat sistem berjalan normal, pilih latency atau consistency (L atau C). Paruh kedua tidak pernah disebut CAP, padahal itulah yang kita hadapi setiap hari.
Penyebabnya adalah replication. Menunggu replica mengonfirmasi write butuh minimal satu round trip jaringan. Sebagai ilustrasi saja, dengan asumsi round trip 40 ms, request yang melakukan 10 commit sinkron berurutan menunggu minimal 10 kali 40 ms, yaitu 400 ms, yang tidak dibayar jika commit dilakukan lokal. Jadi sistem PC/EC membayar latency demi consistency setiap saat, sedangkan sistem PA/EL memilih kecepatan di kedua keadaan.
Tabel ini merangkum default yang terdokumentasi dan knob yang menggeser tiap sistem sepanjang spektrum. Database jarang satu huruf tetap, karena sebagian besar setting ini bisa diatur per cluster atau bahkan per transaksi.
| Database | Perilaku default | Knob ke arah consistency | Saat replica tidak terjangkau |
|---|---|---|---|
| PostgreSQL streaming replication | Synchronous replication mati kecuali synchronous_standby_names diisi, jadi commit tidak menunggu replica | synchronous_standby_names dengan FIRST atau ANY, plus synchronous_commit | Saat sync aktif, commit menunggu dan bisa tidak pernah selesai jika standby yang diwajibkan hilang |
| MongoDB replica set | Write concern default implisit adalah majority, kecuali pada beberapa setup arbiter yang memakai w:1 | w: majority, opsional dengan wtimeout | Sisi minoritas tidak bisa mengumpulkan acknowledgement majority, sehingga write tidak di-acknowledge |
| Redis master dengan replica | Replication asynchronous, latency rendah, ada jendela kehilangan data | WAIT dan min-replicas-to-write mempersempit jendela tetapi tidak memberi strong consistency | Dengan min-replicas-to-write, master menolak write bila replica yang terjangkau terlalu sedikit |
| Cassandra | Versi default digolongkan PA/EL: available saat partition, latency rendah saat normal | Consistency level lebih tinggi per request, menukar latency dengan read yang lebih segar | Tetap available dan bisa menyajikan data basi sampai replica konvergen |
Baca tabel ini sebagai peta default, bukan vonis. PostgreSQL bawaan berperilaku seperti satu node dengan salinan asynchronous, MongoDB condong ke CP secara default, Redis condong ke AP dan cepat, dan Cassandra digolongkan PA/EL oleh artikel PACELC, sehingga kata yang sama, replication, menyembunyikan janji yang sangat berbeda.
Dokumentasi Redis menyatakan bahwa WAIT tidak mengubah sekumpulan instance menjadi sistem CP: write yang sudah di-acknowledge masih bisa hilang saat failover. Jangan menjadikan replica set Redis sebagai source of truth untuk uang hanya karena WAIT tersedia.
Semua ini opsi nyata dari dokumentasi resmi. Jebakannya ada di komentar, karena perilaku berbahaya muncul saat jaminan tidak bisa dipenuhi.
# --- PostgreSQL primary (postgresql.conf): lean CP for the ledger ---
# Commits wait until 2 of the 3 named standbys have the WAL record.
synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
synchronous_commit = on
# Trap: if fewer than 2 standbys are streaming, commits block (no timeout).
# Individual low-value transactions can opt out: SET LOCAL synchronous_commit = local;
// --- MongoDB (mongosh): majority acknowledgement, bounded wait ---
db.payments.insertOne(
{ invoiceId: "INV-1042", amount: 85000 },
{ writeConcern: { w: "majority", wtimeout: 5000 } }
);
// If a majority is unreachable, the write is not acknowledged within 5 s.
# --- Redis: asynchronous by default; narrow the data-loss window ---
# redis.conf on the master
min-replicas-to-write 1
min-replicas-max-lag 10
# per write, ask for 1 replica acknowledgement, waiting up to 100 ms
SET session:abc 1
WAIT 1 100
# Trap: WAIT does NOT make Redis a CP system; acknowledged writes can still be lost.Perhatikan polanya: setting CP menambah penantian dan kemungkinan macet, setting AP menambah jendela kehilangan data. Memilih berarti memilih kegagalan mana yang lebih siap ditangani aplikasi Anda, commit yang tertahan atau write yang hilang.
Pakai CAP sebagai daftar pertanyaan tentang data, bukan label untuk database. Pada contoh carwash, catatan penjualan dan session cache butuh jawaban berbeda, dan satu stack bisa menampung keduanya: Postgres untuk uang, Redis untuk session.
Jika Anda menjalankan satu node PostgreSQL di satu server, seperti banyak deployment ERP dan POS kecil, tidak ada partition antar replica yang perlu dipikirkan, dan CAP muncul di batas lain: antara perangkat klien dan server. Klien POS yang bisa offline adalah keputusan AP di batas itu, entah ada yang menamainya atau tidak.
CAP bukan aturan pilih dua. Ia pengingat bahwa saat partition kita memilih antara menolak dan berbeda-beda data, dan PACELC menambahkan bahwa consistency dibayar dengan latency bahkan di hari baik. Putuskan per dataset, baca default terdokumentasi dari database yang Anda pakai, dan uji kegagalannya sebelum pelanggan yang menemukannya.