Lesson 0011 · System Design · Modul Data · ±20 menit

CAP, PACELC, dan memilih consistency model

Apa yang sebenarnya dikatakan CAP, kenapa PACELC lebih berguna di interview, dan cara memilih antara strong consistency, eventual consistency, dan read-your-writes

Sebelumnya, lesson 0010 membagi data ke banyak node, dan lesson 0009 menyalinnya ke replica. Begitu data ada di lebih dari satu node, setiap write harus sampai ke salinan lain lewat jaringan, dan jaringan bisa lambat atau putus. Lesson terakhir modul Data ini memberi bahasa untuk trade-off itu.

Target lesson ini: Anda bisa menjawab "Jelaskan CAP. Untuk fitur X, Anda memilih consistency atau availability?" tanpa catatan, dalam 60 detik: CAP hanya berlaku saat partition, PACELC menambah trade-off latency vs consistency saat normal, strong vs eventual consistency dengan contoh fitur, read-your-writes, dan quorum R + W > N.

1. CAP: pilihan saat jaringan putus

Tiga sifat: Consistency (setiap read melihat write terakhir, seolah hanya ada satu salinan data), Availability (setiap request ke node yang hidup mendapat jawaban), dan Partition tolerance (sistem tetap berjalan walau pesan antar node hilang). Gilbert dan Lynch membuktikan bahwa di jaringan asinkron tidak mungkin membuat objek read/write yang menjamin availability dan atomic consistency sekaligus di semua eksekusi, termasuk eksekusi yang kehilangan pesan. ^[1]

Karena partition di sistem terdistribusi tidak bisa dihindari, pilihan nyatanya hanya dua saat partition terjadi: tolak sebagian request supaya tetap konsisten (CP), atau tetap menjawab dengan data yang mungkin lama (AP). Abadi menekankan bahwa CAP hanya bicara tentang kegagalan: "CAP allows the system to make the complete set of ACID … guarantees alongside high availability when there are no partitions." ^[2]

Saat pesan dari node 1 tidak sampai, node 2 harus memilih: konsisten (menolak) atau available (menjawab data lama).

2. PACELC: trade-off juga ada saat normal

PACELC (dibaca "pass-elk"): "if there is a partition (P), how does the system trade off availability and consistency (A and C); else (E), when the system is running normally in the absence of partitions, how does the system trade off latency (L) and consistency (C)?" Bagian ELC "only applies to systems that replicate data". ^[2] Inilah trade-off yang Anda temui setiap hari: replikasi sinkron (konsisten, lebih lambat) vs asinkron (cepat, bisa tertinggal) dari lesson 0009.

ada partition?→ ya: pilih A atau C→ tidak (else): pilih L atau C

Kelas	Contoh (Abadi 2012)	Artinya
PA/EL	Dynamo, Cassandra, Riak (default)	"if a partition occurs, they give up consistency for availability, and under normal operation they give up consistency for lower latency"
PC/EC	VoltDB/H-Store, Megastore; BigTable, HBase	"refuse to give up consistency, and will pay the availability and latency costs to achieve it"

Kutipan tabel: ^[2]. Di interview, menyebut "PA/EL" atau "PC/EC" untuk komponen yang Anda pilih menunjukkan Anda paham bahwa trade-off-nya tidak hanya saat jaringan putus.

Latihan 1 — CAP dan PACELC

Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0019.

Kuis di lesson ini adalah feedback cepat, bukan bukti penguasaan; yang dicatat hanya hasil review 0019.

3. Consistency model: strong, eventual, read-your-writes

Strong consistency. Setiap read melihat write terakhir yang sudah di-commit. Wajib untuk saldo, stok saat checkout, username unik, lock.
Eventual consistency. Replika boleh sempat berbeda, tapi kalau write berhenti, semuanya akhirnya sama. Dynamo: "all updates reach all replicas eventually." ^[3] Cukup untuk jumlah like, feed, hitungan view.
Read-your-writes. Jaminan di tengah: user selalu melihat tulisannya sendiri, walau user lain mungkin melihat data lama. Dynamo menyebut optimasi yang memilih node yang tadi melayani read sebelumnya untuk "increasing the chances of getting 'read-your-writes' consistency." ^[3] Cocok untuk edit profil dan posting komentar (lihat juga penanganan replication lag di 0009).

Quorum singkat: N, R, W

Di sistem leaderless seperti Dynamo, setiap data disalin ke N node. "R is the minimum number of nodes that must participate in a successful read operation", W untuk write. "Setting R and W such that R + W > N yields a quorum-like system", dan konfigurasi yang umum di Amazon adalah (N, R, W) = (3, 2, 2). Harganya: "the latency of a get (or put) operation is dictated by the slowest of the R (or W) replicas." ^[3] Intuisinya: dengan N=3, W=2, R=2, set node yang ditulis dan yang dibaca pasti beririsan minimal satu node, jadi read biasanya melihat versi terbaru.

Catatan untuk tidak berlebihan di interview: Abadi menulis bahwa sistem seperti ini mendapat konsistensi lebih dengan menaikkan R + W "at the expense of latency (although they cannot achieve full consistency as defined by Gilbert and Lynch, even if R + W > N)." ^[2] Dynamo sendiri memakai "sloppy quorum" saat node gagal, demi availability. ^[3]

Latihan 2 — Consistency model dan quorum

Jawab tanpa scroll ke atas.

4. Kapan tidak perlu

Komponen di sini adalah datastore terdistribusi multi-node dengan consistency yang bisa diatur (leaderless, quorum, multi-region), dan diskusi CAP yang menyertainya.

Sinyal yang membenarkan. Data memang harus direplikasi ke banyak node atau region dan sistem harus tetap menerima write walau sebagian node atau link putus (mis. keranjang belanja yang tidak boleh menolak write), pada skala yang sudah terukur melampaui satu leader + standby.
Biaya dan risiko. Eventual consistency memindahkan kompleksitas ke aplikasi: versi yang bentrok harus direkonsiliasi (Dynamo memakai vector clock, "a list of (node, counter) pairs" ^[3]), data lama terbaca, dan bug yang sulit direproduksi. Quorum menambah latency (yang paling lambat dari R atau W replika).
Alternatif lebih murah. Satu database leader (strong consistency gratis dari satu sumber kebenaran), ditambah standby untuk failover dan read replica untuk beban baca; read-your-writes cukup dengan membaca dari leader setelah write. Untuk 1.000 user aktif harian di satu region, pertanyaan CAP hampir tidak relevan: jawab "satu leader, konsisten".

Kalimat untuk interview: "Untuk pembayaran saya pilih CP: lebih baik menolak sementara daripada saldo salah. Untuk hitungan like, AP dengan eventual consistency cukup. Pada skala ini keduanya masih bisa dilayani satu PostgreSQL; datastore leaderless baru masuk kalau write harus tetap diterima saat region putus."

Latihan lisan — Ucapkan dengan suara keras

Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai.

"Jelaskan CAP dan PACELC. Untuk sistem e-commerce, bagian mana yang Anda buat strong consistent dan mana yang eventual?" (60 detik)

Bandingkan dengan jawaban contoh dan checklist-nya

"CAP bilang saat terjadi network partition, sistem yang direplikasi harus memilih: tetap konsisten dengan menolak sebagian request, atau tetap available dengan risiko data lama. Partition tidak bisa dihindari, jadi pilihannya CP atau AP, dan itu hanya berlaku saat partition. PACELC melengkapinya: saat normal pun ada trade-off latency vs consistency, misalnya replikasi sinkron vs asinkron. Dynamo dan Cassandra default-nya PA/EL, BigTable dan HBase PC/EC. Di e-commerce, saldo, pembayaran, dan stok saat checkout harus strong consistent; lebih baik menolak sementara daripada menjual barang yang tidak ada. Jumlah review, rekomendasi, dan feed cukup eventual. Untuk edit profil saya pakai read-your-writes: user membaca dari leader setelah menulis. Kalau memakai datastore leaderless, quorum R + W > N, misalnya 3, 2, 2, membuat read biasanya melihat write terbaru dengan biaya latency. Pada skala kecil, satu database leader sudah memberi strong consistency tanpa diskusi CAP."

Checklist: apakah Anda menyebut…

CAP: saat partition, pilih consistency atau availability (CP vs AP), bukan "pilih 2 dari 3" bebas?
PACELC: saat normal ada trade-off latency vs consistency (sync vs async replication)?
contoh fitur yang butuh strong consistency (saldo, stok, pembayaran)?
contoh fitur yang cukup eventual consistency (like, feed, rekomendasi)?
read-your-writes atau quorum R + W > N sebagai jalan tengah, dengan biaya latency?
membenarkan datastore terdistribusi dengan angka atau kebutuhan (satu leader cukup untuk skala kecil)?

Lulus jika minimal 4 dari 6.

Bacaan lanjutan (opsional, tidak dihitung dalam durasi) Abadi 2012, "Consistency Tradeoffs in Modern Distributed Database System Design", IEEE Computer, 6 halaman (±20 menit). Paling berguna untuk memahami kenapa CAP saja tidak cukup.

Berikutnya, Review 1: pool Fondasi + Skalabilitas (0001–0007). Modul Data ini diuji di Review 2 (0019), bersama modul Caching.

Istilah: GLOSSARY.md (bagian "Data") · Indeks: semua lesson System Design

Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "apa beda consistency di CAP dan consistency di ACID?", "kenapa R + W > N tetap tidak menjamin linearizability?", atau "bagaimana menjelaskan CP vs AP untuk sistem chat?"

Sumber: [1] Gilbert & Lynch 2002, Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services (SIGACT News) · [2] Abadi 2012, Consistency Tradeoffs in Modern Distributed Database System Design (IEEE Computer) · [3] DeCandia et al. 2007, Dynamo: Amazon's Highly Available Key-value Store (SOSP)