CAP Theorem

Memahami CAP Theorem dan implikasinya dalam memilih database dan merancang sistem terdistribusi

Apa itu CAP Theorem

Teorema yang dikemukakan oleh Eric Brewer (2000), dibuktikan secara formal oleh Gilbert dan Lynch (2002)
Menyatakan bahwa sistem terdistribusi tidak bisa menjamin ketiga properti berikut secara bersamaan:
- Consistency
- Availability
- Partition Tolerance
Dalam kondisi network partition, sistem harus memilih antara Consistency atau Availability

Setiap read mendapatkan write terbaru atau error
Semua node melihat data yang sama pada waktu yang sama
Contoh: setelah transfer saldo berhasil, saldo yang tampil di semua device langsung terupdate

Setiap request mendapat response (bukan error), meskipun mungkin bukan data terbaru
Sistem selalu beroperasi dan merespons
Contoh: aplikasi tetap bisa diakses meskipun beberapa node gagal

Sistem tetap beroperasi meskipun ada network partition (komunikasi antar node terputus)
Dalam sistem terdistribusi nyata, network partition pasti bisa terjadi
Karena itu, Partition Tolerance biasanya tidak bisa diabaikan

Karena Partition Tolerance harus ada, pilihan nyata adalah:

Saat network partition, sistem memilih untuk tidak merespons daripada memberikan data tidak konsisten
Prioritas: data selalu benar
Contoh sistem: HBase, Zookeeper, etcd, MongoDB (dalam mode tertentu)
Cocok untuk: transaksi keuangan, inventory management, sistem yang tidak boleh ada data conflict

Saat network partition, sistem tetap merespons tapi mungkin dengan data yang tidak up-to-date
Prioritas: sistem selalu available
Contoh sistem: Cassandra, DynamoDB, CouchDB
Cocok untuk: social media feeds, shopping cart, sistem toleran terhadap eventual consistency

Konsep yang sering muncul dalam sistem AP:

Data akan konsisten pada akhirnya, tapi mungkin ada jeda waktu
"Eventually" bisa berarti milidetik atau beberapa detik
Contoh: update profil di satu data center butuh waktu propagasi ke data center lain
Pola: DNS propagation, shopping cart di e-commerce besar

Keterbatasan CAP: hanya membahas saat ada partition. PACELC memperluas:

Jika ada Partition (P): pilih antara Availability (A) atau Consistency (C)
Else (E) — saat sistem normal: pilih antara Latency (L) atau Consistency (C)

Menambahkan dimensi latency yang relevan dalam operasional normal.

Kebutuhan	Rekomendasi	Contoh
Transaksi keuangan, tidak boleh inconsistent	CP	PostgreSQL, MySQL dengan replication
Social media, traffic tinggi, toleran stale data	AP	Cassandra, DynamoDB
Koordinasi distribusi (config, lock)	CP	Zookeeper, etcd
Analytics, bisa ada eventual consistency	AP	Cassandra, HBase
General purpose	CA (single node) atau CP	PostgreSQL, MongoDB

Lebih baik user bisa add to cart dengan data sedikit stale daripada cart tidak bisa diakses
Conflict resolution: merge cart saat checkout

Pahami kebutuhan bisnis sebelum memilih database — bukan semua sistem butuh strong consistency
Tidak semua data dalam satu sistem memiliki kebutuhan consistency yang sama
Beberapa sistem modern (Spanner, CockroachDB) mendekati CA dengan teknik khusus, tapi dengan trade-off latency
Dokumentasikan keputusan pilihan database beserta alasannya dalam ADR