CAP Theorem Trade-offs — System Design

CAP Theorem menyatakan bahwa dalam sistem terdistribusi, kamu hanya bisa menjamin 2 dari 3 properti secara bersamaan: Consistency (C) /\ / \ / \ / ?? \ / \ / \

CAP Theorem menyatakan bahwa dalam sistem terdistribusi, kamu hanya bisa menjamin 2 dari 3 properti secara bersamaan:

          Consistency (C)
              /\
             /  \
            /    \
           /  ??  \
          /        \
         /          \
Availability (A) ── Partition Tolerance (P)

Tiga properti CAP:

C — Consistency (Konsistensi) Setiap read mendapat data terbaru atau error. Semua node melihat data yang sama pada waktu yang sama.

A — Availability (Ketersediaan) Setiap request mendapat response (bukan error), meski tidak selalu berisi data terbaru.

P — Partition Tolerance (Toleransi Partisi) Sistem tetap beroperasi meski ada kegagalan jaringan (network partition) antara node-node.

Mengapa hanya bisa pilih 2?

Bayangkan 2 node database (Node A dan Node B) tiba-tiba tidak bisa
berkomunikasi (network partition):

Pilihan 1 — Pilih C + P (korbankan A):
  → Node A menolak semua request sampai bisa sync dengan Node B
  → Sistem tidak available, tapi data pasti konsisten

Pilihan 2 — Pilih A + P (korbankan C):
  → Node A dan Node B terus menerima request secara independen
  → Data bisa berbeda di kedua node (inconsistent)
  → Eventual consistency: akan sync nanti saat network pulih

Pilihan 3 — C + A (korbankan P):
  → Hanya bisa ada di sistem dengan 1 node (tidak terdistribusi)
  → Tidak realistis untuk sistem modern yang butuh HA

Kategori sistem berdasarkan CAP:

Tipe Contoh Trade-off
CP HBase, Zookeeper, MongoDB* Tidak available saat partisi
AP Cassandra, DynamoDB, CouchDB Data mungkin stale saat partisi
CA RDBMS tradisional (single node) Tidak partition-tolerant

PACELC — model yang lebih realistis:

CAP hanya berlaku saat ada partisi. PACELC memperluas ini:

If Partition: tradeoff C vs A
Else (normal): tradeoff Latency vs Consistency

// Contoh trade-off praktis:
// Bank (pilih CP):
function transfer(from, to, amount) {
  // Gunakan distributed transaction
  // Jika tidak bisa confirm semua node → reject request
  // Lebih baik gagal dari pada data tidak konsisten
}

// Social media like count (pilih AP):
function getLikeCount(postId) {
  // Baca dari node terdekat
  // Mungkin sedikit stale (2000 vs 2001 likes)
  // Tidak masalah, user tidak perlu hitungan persis real-time
}

Consistency levels dalam AP system:

Strong Consistency   → Semua node harus sync (seperti CP)
Eventual Consistency → Akan konsisten, tapi tidak sekarang
Read-your-writes     → User selalu lihat perubahan yang dia buat sendiri
Monotonic reads      → User tidak pernah melihat data "lebih lama" dari sebelumnya
Causal consistency   → Operasi yang related tampil berurutan dengan benar

Pilihan praktis:

8 Fallacies of Distributed Computing

CAP theorem adalah kasus spesifik dari problem yang lebih umum. Peter Deutsch dan kawan-kawan di Sun Microsystems (1994) merumuskan 8 asumsi keliru yang sering dibuat pengembang tentang distributed system. Semua pattern system design (termasuk CAP) adalah respon terhadap fallacies ini:

# Fallacy Realita Connection ke CAP
1 Network is reliable Network putus secara rutin ⟹ butuh P (partition tolerance)
2 Latency is zero Latency signifikan antar datacenter ⟹ C atau A terpaksa trade-off saat P
3 Bandwidth is infinite Bandwidth terbatas dan mahal ⟹ tidak semua data bisa direplikasi real-time
4 Network is secure Packet bisa di-intercept/tamper ⟹ butuh encryption, auth di setiap layer
5 Topology doesn't change DNS, IP, lokasi berubah ⟹ service discovery wajib dinamis
6 There is one administrator Multi-tim, multi-org, multi-cloud ⟹ koordinasi lintas domain sulit
7 Transport cost is zero Serialization, TLS handshake, routing = CPU + $ ⟹ batch + compress berarti
8 The network is homogeneous Protokol, versi, vendor berbeda ⟹ standard dan compat layer

Hubungan ke CAP: CAP theorem pada dasarnya adalah konsekuensi formal dari fallacy #1 dan #2. Kalau network andal dan latency nol (= fallacy false), CAP tidak akan jadi masalah — kita bisa punya strong consistency + high availability sekaligus.

Tapi karena network tidak andal dan ada latency, kita dipaksa memilih. Dan karena bandwidth tidak infinite, full replication tidak praktis. Dan seterusnya.

Pelajaran praktis: saat mendesain sistem, cek apakah desainmu diam-diam mengasumsikan salah satu fallacy di atas. Kalau iya → di situlah sistem akan patah di production.

🎭 Analogi sehari-hari: Tim WhatsApp grup family. Network bagus = semua bisa baca pesan + balas. Tiba-tiba sinyal mati di rumah satu anggota.

WhatsApp pilih A — lebih penting bisa kirim daripada perfectly consistent.

💡 CAP bukan biner — ada spectrum:

Pilih level konsistensi sesuai kebutuhan, bukan all-or-nothing.

⚠️ Jebakan klasik:

🎯 Decision framework:

TL;DR: CAP = di network partition, harus pilih C atau A. Modern reality: spectrum, bukan binary. PACELC tambah dimensi latency. Pilih level consistency sesuai use case. Finansial = CP, social media = AP. 8 Fallacies of Distributed Computing = sumber semua trade-off.