Mengapa Sistem Terdistribusi Tidak Dapat Memiliki Semuanya

Sistem terdistribusi modern penuh dengan kompromi. Performa, keandalan, skalabilitas, dan konsistensi tidak datang begitu saja — Anda selalu harus membayar harganya. Di sinilah teorema CAP berperan: ini adalah titik awal untuk memahami kompromi yang tak terelakkan dalam desain terdistribusi.

Mengapa teorema CAP benar? Apa yang sebenarnya dijelaskannya? Dan, yang terpenting, apakah itu cukup? Dalam artikel ini, kita akan membahas teorema CAP, keterbatasannya, kritik yang dihadapinya, dan bagaimana ide-ide baru seperti PACELC mendorong diskusi ini ke depan. Mari kita bahas lebih dalam.

Teorema CAP

Versi pertama teorema CAP dimulai sebagai perdebatan antara ASAM vs. BASA . Namun seiring berjalannya waktu, teorema ini berkembang, memperoleh pembuktian formal, dan berkembang menjadi teorema CAP seperti yang kita kenal sekarang.

Teorema CAP menyatakan bahwa sistem terdistribusi dapat memenuhi paling banyak dua dari tiga properti secara bersamaan :

• Konsistensi
• Tersedianya
• Toleransi Partisi

Keterbatasan ini memaksa para insinyur untuk membuat keputusan yang sulit, tergantung pada tujuan sistem dan realitas lingkungan terdistribusi mereka.

Konsistensi

Konsistensi dalam CAP tidak sama dengan konsistensi dalam transaksi ACID . Dalam teorema CAP, hal ini mengacu pada linearisasi atau konsistensi yang kuat . Artinya, semua node dalam sistem terdistribusi harus selalu menyajikan satu tampilan data terkini , terlepas dari node mana yang memproses permintaan. Ini berarti bahwa setiap operasi baca mencerminkan penulisan terbaru, tidak peduli node mana yang Anda kueri.

💡 Konsistensi dalam ACID, di sisi lain, berfokus pada upaya memastikan bahwa transaksi membawa basis data dari satu status valid ke status valid lainnya, mengikuti aturan yang ditetapkan oleh skema basis data. Konsistensi lebih pada penerapan batasan integritas (seperti kunci asing, batasan unik, dsb.) dan memastikan basis data tidak dibiarkan dalam status tidak valid, bahkan saat terjadi crash.

Tersedianya

Ketersediaan dalam CAP berarti bahwa setiap node yang tidak gagal harus mengembalikan respons untuk setiap permintaan yang diterimanya, terlepas dari partisi jaringan . Dengan kata lain, jika node yang sehat mendapat permintaan, ia harus memproses dan menanggapinya. Namun, CAP tidak menjamin respons akan selalu "benar" atau terkini — ia hanya memastikan node tidak gagal secara diam-diam (misalnya, dalam sistem AP node mungkin menanggapi dengan data basi selama partisi untuk memastikan ketersediaan).

💡 Eric Brewer (penulis asli CAP) awalnya menjelaskan properti ini sedikit lebih fleksibel sebagai: "hampir semua kueri harus mendapat respons". Namun, dalam pembuktian formal CAP, ketersediaan dibuat lebih ketat, yang mengharuskan "setiap kueri menerima respons selama node yang menanganinya dalam kondisi baik".

Namun, dalam praktiknya, ketersediaan bukanlah jaminan mutlak — ketersediaan sering kali bergantung pada batasan khusus sistem, seperti seberapa lama Anda bersedia menunggu respons. Untuk sistem di dunia nyata, waktu respons (atau batas waktu) memainkan peran penting dalam membentuk SLA (perjanjian tingkat layanan) Anda, meskipun CAP sendiri tidak secara langsung memperhitungkan latensi. Selengkapnya tentang hal ini dalam posting blog ini .

Toleransi partisi

Toleransi partisi adalah tentang bertahan dari kegagalan jaringan. Jika node tidak dapat berkomunikasi karena pemisahan jaringan (partisi), sistem harus tetap memenuhi jaminan konsistensi atau ketersediaannya, tergantung pada pilihan desainnya. Partisi terjadi ketika node tidak dapat berkomunikasi karena paket terputus, batas waktu, atau pemisahan jaringan.

Sistem terdistribusi tidak hidup di dunia dongeng dengan jaringan yang sempurna. Paket-paket terputus, terjadi batas waktu, dan lonjakan latensi tidak dapat dihindari. Karena itu, toleransi partisi tidak dapat dinegosiasikan dalam sistem terdistribusi apa pun — partisi akan terjadi cepat atau lambat, jadi Anda tidak dapat "memilih" untuk mengabaikannya, tidak peduli seberapa menggoda kedengarannya.

Dalam CAP, toleransi partisi tidak berarti sistem terus berjalan seolah tidak terjadi apa-apa. Artinya, sistem harus memutuskan apakah akan memprioritaskan ketersediaan (AP) atau konsistensi (CP) selama partisi. Jika Anda mengabaikan toleransi partisi, pada dasarnya Anda akan membangun sistem monolitik yang tidak terdistribusi.

CAP dijelaskan

Cara termudah untuk memahami CAP adalah dengan mempertimbangkan partisi jaringan — situasi di mana dua bagian dari sistem terdistribusi tidak dapat berkomunikasi satu sama lain. Dalam skenario seperti itu, sistem menghadapi tiga kemungkinan hasil:

1. Jika satu bagian sistem menerima pembaruan sementara yang lain terisolasi, kedua bagian tersebut akan memiliki status yang tidak konsisten. Hal ini mengakibatkan hilangnya C (Konsistensi) .
2. Jika sistem memilih untuk tetap konsisten , sistem harus memblokir pembaruan di satu atau kedua bagian partisi untuk memastikan status terpadu di semua node. Hal ini menyebabkan hilangnya A (Ketersediaan) karena beberapa permintaan akan ditolak atau ditunda tanpa batas waktu.
3. Jika sistem memilih untuk tetap tersedia (A) dan konsisten (C) tanpa menoleransi partisi (P), sistem tersebut tidak benar-benar terdistribusi. Ini akan mengharuskan node untuk berinteraksi dan merekonsiliasi status, yang tidak mungkin dilakukan selama partisi.

Jadi, selama partisi , sistem hanya dapat memenuhi dua dari tiga properti (C, A, atau P) . Setelah partisi teratasi (yaitu node berinteraksi lagi), sistem dapat memperoleh kembali ketiga properti tersebut, tetapi selama partisi itu sendiri , tradeoff tidak dapat dihindari.

Implikasi dari teorema tersebut

Konsekuensi dari teorema untuk sistem asinkron adalah bahwa hanya tiga kombinasi konsistensi, ketersediaan, dan toleransi partisi yang mungkin:

AP (Ketersediaan + Toleransi Partisi)

Sistem jenis ini menanggapi permintaan, tetapi data yang dikembalikan mungkin tidak selalu mutakhir, dengan pembaruan data yang lebih lambat tetapi "selalu" tersedia. Contoh sistem semacam itu adalah DNS, DynamoDB, dan Cassandra.

CP (Konsistensi + Toleransi Partisi)

Sistem jenis ini selalu mengembalikan data terkini, tetapi beberapa, atau bahkan semua, node dalam sistem mungkin tidak merespons jika dipartisi. Sistem ini memberikan pembaruan atomik tetapi dapat menyebabkan waktu habis. Basis data NoSQL seperti Google BigTable, MongoDB, HBase, dan Redis semuanya adalah sistem jenis ini.

CA (Konsistensi + Ketersediaan)

Sistem jenis ini selalu mengembalikan data terkini saat tidak ada partisi. Karena keterbatasan terakhir, biasanya sistem seperti itu hanya digunakan dalam satu mesin. Contohnya adalah basis data relasional klasik.

Pada kenyataannya, kita memilih antara CP dan AP karena CA pada dasarnya adalah monolit tanpa partisi. Untuk sistem berskala besar, perancang tidak dapat mengabaikan P dan karena itu memiliki pilihan yang sulit antara C dan A.

Dalam CA, kegagalan node berarti layanan tidak tersedia sama sekali. Namun, hal ini tidak menonaktifkan skalabilitas, karena kita dapat mengkloning monolit independen dan mendistribusikan beban ke atasnya.

Kritik terhadap Teorema CAP

Teorema CAP telah menjadi konsep dasar dalam sistem terdistribusi, tetapi bukan tanpa keterbatasan. Meskipun jelas dalam menyajikan gagasan tentang tradeoff, teorema CAP sering dikritik karena terlalu menyederhanakan realitas yang kompleks, yang menyebabkan kesalahpahaman dan penerapan yang salah.

1. Kompromi Hanya Berlaku Selama Partisi

Salah satu kritik yang paling umum adalah bahwa tradeoff teorema CAP — memilih antara konsistensi (C) dan ketersediaan (A) — hanya berlaku ketika partisi jaringan (P) benar-benar terjadi. Dalam operasi normal, ketika jaringan stabil dan tidak ada partisi, tidak ada tradeoff inheren antara konsistensi dan ketersediaan.

Lebih jauh lagi, tradeoff ini tidak berlaku secara universal di seluruh sistem. Dalam sistem terdistribusi yang sama:

• Berbagai bagian sistem mungkin mengalami pertentangan berbeda berdasarkan konteks (seperti lokasi pengguna, jenis data).
• Operasi tertentu mungkin mengutamakan konsistensi sementara yang lain mengutamakan ketersediaan.
• Keputusan dapat bervariasi pada saat runtime tergantung pada faktor-faktor seperti beban, latensi, atau persyaratan pengguna.

Nuansa ini sering kali hilang dalam diskusi tingkat tinggi mengenai CAP, yang mengarah kepada klasifikasi sistem yang terlalu disederhanakan sebagai "CP" atau "AP" secara menyeluruh.

2. CAP Mengabaikan Latensi

Kritik penting lainnya adalah bahwa teorema CAP tidak memperhitungkan latensi , meskipun latensi dan partisi saling terkait erat dalam praktik. Misalnya:

• Jaringan yang lambat (latensi tinggi) mungkin tampak tidak dapat dibedakan dari sebuah partisi.
• Batas waktu—yang digunakan untuk mendeteksi kegagalan—bersifat subjektif dan sangat bergantung pada desain sistem dan kondisi jaringan. Apa yang didefinisikan oleh satu sistem sebagai "partisi" mungkin hanya merupakan penundaan sementara bagi sistem lain.

Dalam sistem terdistribusi di dunia nyata, ketika terjadi partisi atau latensi tinggi, sistem harus membuat keputusan dalam periode waktu habis : memprioritaskan ketersediaan dengan mengembalikan hasil yang mungkin basi, atau memprioritaskan konsistensi dengan menunggu lebih lama (dan berpotensi gagal merespons). Pandangan biner CAP tidak menangkap kompleksitas keputusan ini.

3. Properti CAP Tidak Bersifat Biner

Teorema CAP menyajikan konsistensi, ketersediaan, dan toleransi partisi sebagai properti biner—Anda memilikinya atau tidak. Namun dalam praktiknya, ketiga properti tersebut ada dalam spektrum :

• Ketersediaan bukanlah properti biner "aktif/nonaktif"—ia berkisar dari 0% hingga 100%. Misalnya, suatu sistem dapat menjamin ketersediaan 99,99%, tetapi hal itu masih memungkinkan untuk periode tidak tersedia yang singkat.
• Konsistensi memiliki tingkatan yang bervariasi, dari konsistensi akhir hingga konsistensi kausal hingga konsistensi yang kuat. Tidak semua aplikasi memerlukan linearisasi penuh.
• Toleransi partisi itu sendiri bukanlah peristiwa yang jelas. Sistem mungkin tidak sepakat tentang keberadaan partisi (misalnya, satu node melihat batas waktu sebagai kegagalan, sementara node lain tetap beroperasi secara normal).

Sifat properti yang berkesinambungan ini membuat CAP terlalu sederhana untuk memodelkan kompleksitas sistem terdistribusi modern.

Teorema PACELC

Meskipun CAP merevolusi pemahaman kita tentang tradeoff dalam sistem terdistribusi, itu bukanlah kata terakhir tentang pokok bahasan tersebut. Teorema PACELC yang dijelaskan oleh Daniel J. Abadi dianggap sebagai pendekatan alternatif untuk desain sistem terdistribusi. Pendekatan ini didasarkan pada model CAP, tetapi selain konsistensi, ketersediaan, dan toleransi partisi, pendekatan ini juga mencakup latensi dan pengecualian logis antara kombinasi konsep-konsep ini.

PACELC memperkenalkan dua mode operasi berbeda untuk sistem terdistribusi:

1. Mode partisi ( PAC ): Apa tradeoff yang dibuat sistem saat partisi terjadi? Di sini, kami meninjau kembali tradeoff CAP klasik antara ketersediaan (A) dan konsistensi (C) .
2. Mode lain ( ELC ): Apa tradeoff yang dibuat sistem saat tidak ada partisi, dan jaringan berfungsi normal? Dalam mode ini, sistem menghadapi tradeoff yang berbeda — antara latensi (L) dan konsistensi (C) .

Pertukaran Latensi-Konsistensi

Meskipun partisi tidak dapat dihindari dalam sistem terdistribusi, partisi jarang terjadi jika dibandingkan dengan tantangan yang muncul selama operasi normal. Dalam sistem terdistribusi modern, latensi sering kali menjadi hambatan yang lebih besar daripada partisi jaringan, khususnya untuk aplikasi berskala global. Di sinilah PACELC berfokus — dengan mengatasi tradeoff yang terjadi saat sistem beroperasi tanpa partisi. Tidak seperti CAP, yang hanya berfokus pada perilaku selama skenario kegagalan, PACELC menekankan keputusan yang harus diambil arsitek setiap hari untuk menyeimbangkan latensi (L) dan konsistensi (C) :

• Konsistensi yang kuat memerlukan koordinasi dan sinkronisasi antar node untuk mempertahankan tampilan data yang terpadu. Overhead ini menimbulkan penundaan, yang memperlambat waktu respons.
• Sistem latensi rendah (seperti sistem yang mengadopsi eventual continuity) memprioritaskan kecepatan dengan melonggarkan jaminan konsistensi. Sistem ini merespons lebih cepat tetapi terkadang dapat mengembalikan data yang basi atau tidak konsisten.

Dengan memperluas percakapan di luar partisi untuk mencakup operasi normal, PACELC memastikan bahwa kinerja sehari-hari sistem terdistribusi diperlakukan dengan kepentingan yang layak.

Menyimpulkan

Perumusan teorema CAP telah menjadi peristiwa penting dalam komunitas, dan studi tentang dampaknya pada desain sistem terdistribusi telah menunjukkan bahwa perancang sistem terdistribusi tidak boleh membatasi sistem pada dua properti - mereka harus berusaha untuk memaksimalkan jaminan yang diperlukan dalam setiap kasus tertentu. Untuk tujuan ini, masuk akal untuk membagi sistem menjadi beberapa segmen, yang masing-masing memiliki persyaratannya sendiri, dan merancang sistem berdasarkan persyaratan masing-masing segmen.

Teorema CAP telah menjadi landasan pemikiran sistem terdistribusi selama beberapa dekade. Teorema ini memberi kita kerangka kerja untuk bernalar tentang tradeoff yang melekat pada konsistensi, ketersediaan, dan toleransi partisi. Namun dalam banyak hal, ini merupakan penyederhanaan realitas, dengan asumsi pilihan biner dan mengabaikan faktor-faktor penting seperti latensi.

PACELC dibangun berdasarkan CAP, dengan mengakui bahwa:

• Kompromi tetap ada bahkan ketika partisi tidak ada.
• Latensi merupakan perhatian utama dalam desain sistem terdistribusi.

Baik CAP maupun PACELC merupakan perangkat yang berharga, tetapi keduanya bukanlah resep langkah demi langkah untuk membangun sistem. Sebaliknya, keduanya menyediakan model mental untuk mengevaluasi tradeoff dan memahami batasan arsitektur terdistribusi.

Bahan tambahan

• CAP Dua Belas Tahun Kemudian: Bagaimana "Aturan" Telah Berubah
• Cassandra: Panduan Definitif
• Tolong berhenti menyebut database CP atau AP dan Kritik terhadap Teorema CAP oleh Martin Kleppmann
• Catatan tentang Sistem Terdistribusi untuk Young Bloods

Terima kasih telah membaca!

Penasaran tentang sesuatu atau punya pemikiran untuk dibagikan? Tinggalkan komentar Anda di bawah! Lihat blog saya atau ikuti saya melalui LinkedIn , Substack , atau Telegram .