📚 Topik — CAP Theorem & PACELC: Kenapa "CA" Itu Mitos

Kategori: Distributed Systems · Level: Advanced · Tanggal sesi: 19 Oktober 2026

🎯 Tujuan Belajar

Setelah sesi ini, keputusan arsitektur berikut harus lebih tajam:

1. Berhenti memilih "CA" di slide arsitektur — dan bisa menjelaskan ke stakeholder kenapa pilihan itu tidak ada.
2. Memilih per-operasi, per-kelas-data, bukan per-database. Satu sistem bisa CP untuk saldo dan AP untuk keranjang.
3. Menghitung biaya nyata dari pilihan CP: bukan "unavailable", tapi berapa lama dan siapa yang nunggu.
4. Membedakan CAP-C (linearizability) dari ACID-C (constraint) — dua hal berbeda yang sering tertukar di diskusi desain.

🧠 Penjelasan Inti

Definisi formal (Gilbert & Lynch, 2002 — pembuktian formal dari konjektur Brewer 2000):

Teorema: Dalam model network asynchronous (delay tak terbatas, tanpa clock global), tidak ada sistem terdistribusi yang bisa menjamin C dan A secara simultan saat P terjadi. Buktinya via kontradiksi: jika ada partisi, node di sisi berbeda tidak bisa membedakan "peer mati" dari "peer hidup tapi pesannya ditahan". Untuk tetap Available, ia harus menjawab dengan informasi lokal → bisa divergen → C dilanggar. Untuk tetap Consistent, ia harus menolak menjawab → A dilanggar.

Kenapa "CA" mitos: P bukan pilihan desain, tapi properti lingkungan. Network partition terjadi karena: kabel putus, switch reboot, BGP misconfig, NIC drop, GC pause 3 detik yang bikin heartbeat timeout, kernel panic, cloud AZ terisolasi. Engineer tidak bisa "memilih untuk tidak kena partisi". Jadi pilihan sebenarnya cuma dua: CP atau AP saat partisi. Sistem "CA" = sistem single-node (tidak terdistribusi) — dan bahkan itu kena partisi antara aplikasi dan DB-nya.

Penting: CAP hanya bicara saat partisi. Di 99.9% waktu tanpa partisi, CAP tidak memberi guidance apa pun. Itulah kenapa PACELC ada.

⚙️ Cara Kerja Internal

1. Kenapa C dan A benar-benar bertabrakan — mekanismenya

Bayangkan dua node, N1 dan N2, partisi total. Client menulis x = 1 ke N1.

Tanpa partisi:
  N1 ──replikasi──> N2      read di N2 → x=1  ✓ C dan A

Dengan partisi:
  N1 ╳╳╳ N2

  Pilihan CP:  N1 tolak write (butuh quorum), N2 tolak read → A dilanggar
  Pilihan AP:  N1 terima write lokal, N2 jawab x=0 (stale)  → C dilanggar

Tidak ada jalan ketiga. Untuk jawab benar, N2 harus tahu isi N1 — mustahil saat partisi. Untuk jawab cepat, N2 harus jawab tanpa tahu.

2. "Partition" bukan biner — ini yang bikin CAP praktis lebih lunak

Brewer (2012, "CAP Twelve Years Later") mengoreksi interpretasinya sendiri: partisi itu jarang, dan ketika terjadi, pilihannya bukan biner tapi spektrum:

• Deteksi partisi butuh timeout. Karena sistem async tidak bisa membedakan slow vs dead (FLP impossibility), timeout adalah tebakan. Timeout 1s → banyak false positive → sistem jadi unavailable padahal network sehat tapi lag sesaat.
• Recovery: setelah partisi pulih, state harus direkonsiliasi. Ini bagian yang paling sering diabaikan dan paling sering jadi sumber bug produksi.
• Pilihan per-operasi: sistem yang sama bisa CP untuk transfer() dan AP untuk update_last_seen().

3. PACELC — melengkapi CAP (Abadi, 2012, IEEE Computer)

If Partition → A or C. Else → Latency or Consistency.

Saat tidak ada partisi, tetap ada trade-off: untuk konsisten kuat, koordinasi butuh round-trip. Round-trip butuh waktu. Jadi: konsistensi selalu dibayar dengan latency. Ini fisika, bukan pilihan vendor — cahaya dalam fiber ~200.000 km/s, jadi RTT Jakarta–Singapura (~900 km) minimal ~9ms murni propagation, real-world 20–30ms. Cross-region US–Asia: 150–250ms. Tidak ada hardware yang menghapus ini.

Klasifikasi PACELC (dari paper Abadi; koarse, dan bisa berubah antar versi):

* Spanner menarik: ia PC/EC tapi latency-nya rendah karena TrueTime — jam atom/GPS memberi batas error ~7ms, jadi commit-wait-nya pendek. Ini bukti bahwa trade-off bisa digeser dengan biaya hardware, bukan dihapus.

4. Middle ground: session guarantees

Banyak sistem tidak butuh linearizability penuh, tapi tidak mau eventual consistency buta. Yang tersedia:

• Read-your-writes — user selalu lihat write-nya sendiri (route ke primary, atau simpan write timestamp di session).
• Monotonic reads — tidak pernah "mundur" ke state lebih lama.
• Consistent prefix — write terlihat berurutan, tidak melompat.

Ini jauh lebih murah dari linearizability dan menutup 90% keluhan user nyata ("kok data saya hilang?").

🏗️ Diagram — Pohon Keputusan Praktis

Operasi ini menyentuh uang / kuota / stok terbatas?
├─ YA  → CP. Quorum write (W > N/2), tolak saat quorum loss.
│        Konsekuensi: harus punya jalur degradasi (retry queue, antrian).
│        Contoh: transfer, pembayaran, alokasi nomor unik, booking kursi.
└─ TIDAK
   └─ Apakah user bisa mentoleransi melihat data sendiri yang basi?
      ├─ TIDAK (read-your-writes wajib)
      │   → AP + session stickiness / read-from-primary-after-write.
      │     Contoh: profil, setting, post yang baru dibuat.
      └─ YA
          → AP/EL. Eventual consistency + reconciliation job.
            Contoh: feed, counter like, last_seen, rekomendasi, search index.

Pertanyaan lanjutan yang sering dilupakan: siapa yang menang saat konflik? Butuh conflict resolution strategy eksplisit — LWW (timestamp, rawan clock skew), vector clock (deteksi konflik, tapi harus diselesaikan manual), CRDT (merge otomatis, tapi terbatas tipe data).

⚖️ Trade-off & Kapan JANGAN Dipakai

Kapan JANGAN pakai CP (konsistensi kuat):

• Operasi high-throughput yang tidak butuh ordering, mis. counter view, log aktivitas, presence. Membayar koordinasi di sini = buang latency tanpa manfaat.
• Sistem yang harus tetap hidup saat satu region mati total. CP dengan quorum di 2 region dari 3 = region ketiga harus online. Kalau tidak ada, sistem mati total — availability 0.
• Read-heavy geo-distributed yang user-nya sensitif latency. Cross-region quorum read = 200ms+ per request.

Kapan JANGAN pakai AP (eventual consistency):

• Ada invariant yang tidak boleh dilanggar sesaat pun: saldo tidak boleh negatif, kuota tidak boleh oversold, username unik. Eventual consistency di sini = duplikasi yang tidak bisa "di-un-do" secara sosial (dua orang sudah lihat username itu).
• Ketika biaya rekonsiliasi lebih besar dari biaya koordinasi. Rekonsiliasi butuh: deteksi konflik, aturan merge, audit trail, dan sering butuh manusia. Koordinasi butuh ~10ms.
• Regulatory/audit requirement — "kami tidak tahu mana yang benar" bukan jawaban yang diterima auditor.

Biaya tersembunyi CP yang jarang dihitung:

Biaya tersembunyi AP:

🏭 Contoh Produksi & Failure Mode

1. Dynamo (Amazon, 2007) — AP by design, dan alasannya bisnis Paper-nya eksplisit: pilihan "always writable" diambil karena Add to Cart yang gagal = uang hilang. Cart yang konflik di-merge (union semantics), bukan ditolak. Pelajaran: keputusan konsistensi itu keputusan produk, bukan keputusan infrastruktur. Merge semantics harus didesain bersama datanya.

2. GitHub, 21 Oktober 2018 — split-brain 24 jam Partisi network antara datacenter US East Coast dan West Coast. Orchestrator melakukan failover MySQL ke primary baru di sisi yang salah, sementara primary lama masih menerima write dari sisi lain → dua primary. Selama ~24 jam, data divergen dan aplikasi menampilkan state tidak konsisten. Pelajaran: masalahnya bukan "pilih CP atau AP", tapi proses failover-nya sendiri yang butuh fence (STONITH, epoch number, atau lease) agar primary lama tidak bisa menulis. Tanpa fencing, sistem yang secara teori CP bisa berperilaku AP secara tidak sengaja.

3. Last-Write-Wins menghapus data secara diam-diam LWW pakai timestamp dari client. Clock skew antar device bisa menit, bahkan jam. Write yang lebih baru secara logis bisa kalah karena jam device-nya mundur. Tidak ada error, tidak ada log — data hilang diam-diam. Pelajaran: LWW hanya aman kalau kehilangan write tidak berdampak, atau kalau timestamp dari sumber terpusat (HLC, TrueTime).

4. Quorum "mayoritas" tanpa memahami sloppy quorum Cassandra W=QUORUM, R=QUORUM dengan N=3 terlihat seperti strong consistency (R+W > N). Tapi dengan hinted handoff dan sloppy quorum, write bisa diterima node di luar replica set → R+W>N tidak lagi menjamin linearizability. Konsistensi Cassandra bersifat tunable, bukan transaksional — dan read repair butuh waktu. Pelajaran: baca dokumentasi konsistensi sampai level mekanisme, bukan level marketing.

5. "Kami pakai Spanner jadi kami CP" Spanner butuh TrueTime — jam atom + GPS di tiap datacenter, dengan bounded uncertainty. Tanpa itu, commit-wait tidak bisa dihitung. Cloud lain meniru dengan pendekatan berbeda (clock sync + lease). Pelajaran: "CP dengan latency rendah" biasanya berarti membayar hardware khusus atau menerima batas akurasi clock yang lebih longgar. Copy arsitektur tanpa copy asumsinya = bug.

⚠️ Miskonsepsi Umum

✅ Cek Pemahaman

1. Sistem kamu pakai Postgres dengan synchronous replication ke 2 replika di 3 AZ, synchronous_commit = on, ANY 2. Region ke-4 (DR) menerima async. Saat AZ-1 dan AZ-2 terisolasi dari AZ-3, apakah sistem ini CP atau AP? Apa yang terjadi pada write, dan apa yang terjadi pada read dari AZ-3? Apa yang harus dilakukan saat partisi pulih?

2. Sebuah fitur "kuota voucher 1000 unit" dijalankan di Cassandra dengan W=ONE. Apa failure mode-nya saat dua request masuk bersamaan ke node berbeda? Kalau kamu harus mempertahankan Cassandra, di mana kamu menaruh penjagaannya — dan apa konsekuensi latency-nya?

3. Tim kamu bilang "kita butuh strong consistency untuk fitur komentar". Bantah atau dukung dengan argumen teknis: apa yang sebenarnya dibutuhkan user, apa biaya linearizability di sini, dan alternatif apa yang lebih tepat?

🔑 Poin Kunci

• CAP berlaku hanya saat partisi. Tanpa partisi, CAP diam — PACELC yang bicara (latency vs consistency).
• "CA" bukan pilihan. P adalah properti lingkungan, bukan knob desain.
• Keputusan konsistensi itu per-operasi dan per-kelas-data, bukan per-database. Satu sistem hampir selalu butuh keduanya.
• CAP-C ≠ ACID-C. Jangan campur di diskusi desain; bikin kesimpulan salah.
• Biaya CP = latency + blast radius + fencing. Biaya AP = rekonsiliasi + bug non-reproducible. Keduanya nyata, keduanya harus dianggarkan.
• Tanpa conflict resolution eksplisit, AP = data loss yang diam. Tentukan pemenang konflik sebelum memilih AP.
• Failover butuh fence. Sistem CP yang failover tanpa fencing berubah jadi split-brain — AP tanpa sadar.

➡️ Eksplorasi Lanjut

• Consistency models berjenjang — linearizable → sequential → causal → read-your-writes → eventual. Kapan causal cukup? (Causal+ consistency di COPS paper.)
• Consensus internals — Raft (leader election, log replication, safety) vs Paxos. Kenapa Raft menang di implementasi praktis.
• CRDT — G-Counter, LWW-Register, OR-Set, dan batasannya. Kapan merge otomatis mustahil.
• Transactional isolation — read committed vs snapshot isolation vs serializable, dan anomali yang tersisa di tiap level (write skew, phantom).
• Time & ordering — HLC (Hybrid Logical Clock), TrueTime, dan kenapa wall clock tidak bisa dipercaya untuk ordering.
• Bacaan: Brewer, "CAP Twelve Years Later" (IEEE Computer, 2012) · Abadi, "Consistency Tradeoffs in Modern Distributed Database System Design" (IEEE Computer, 2012) · Kleppmann, Designing Data-Intensive Applications, ch. 5 & 9 · Jepsen reports untuk melihat bagaimana klaim konsistensi vendor diuji secara empiris.