Sebelumnya gw pernah bahas ACID pada database. Kali ini bahasannya tentang teori CAP pada database yang dipopulerkan oleh Eric Brewer di akhir 90an dan masih relevan hingga sekarang. CAP Theorem adalah teori yang menjelaskan bahwa pada sistem database maksimal hanya bisa memiliki 2 kombinasi dari 3 elemen CAP. Ketiga elemen itu adalah Consistency, Availability, dan Partition Tolerance.
Consistency
Consistency artinya data yang dibaca adalah data terbaru yang di-commit. Keunggulannya, datanya jadi bersih. User ga akan melihat data kotor seperti data usang sebelum commit terbaru. Misalkan ada produk "Susu" seharga Rp5000. Lalu diubah harganya jadi Rp6000. Setelah commit, saat query selanjutnya harga yang muncul harus Rp6000. Ini beda dengan makna Consistency pada ACID di mana Consistency di ACID artinya data harus konsisten sesuai aturan. Sedangkan pada CAP Theorem, Consistency berbicara tentang data yang linear antara data yang ditulis dengan data yang dibaca. Harusnya biar ga membingungkan elemen ini dinamakan Linearizability aja. Mungkin karena singkatannya jadi kurang keren kali ya, kalau disingkat jadi LAP Theorem kayak kurang enak kedengarannya🤭.
Availability
Availability artinya selama servernya masih berfungsi maka tiap request database wajib segera memberikan response. Keunggulannya, response jadi cepat. Misalnya saat komen di sosial media. Setelah komen dikirim, database akan menyimpannya dan langsung memberikan response sesegera mungkin. Di sini ga ada jaminan data yang diberikan saat query adalah data terbaru atau bukan. Bisa saja inputnya berhasil, tapi saat dibaca datanya belum ada. Bisa jadi data yang muncul masih data yang lama, data terbaru muncul setelah beberapa saat kemudian. Bisa juga malah datanya ketimpa sama perubahan lain sehingga ga akan pernah muncul. Pada elemen ini hal seperti itu dihalalkan😁.
Partition Tolerance
Partition Tolerance artinya system harus tetap beroperasi meskipun sebagian server ada gangguan💪. Pada elemen ini berarti system memiliki lebih dari satu node server. Keunggulannya, jika sebagian server kena gangguan ga masalah karena tugasnya bisa diambil-alih oleh server lain yang ga kena gangguan. Misalkan ada server A, B, dan C. Jika server A mati, maka koneksi akan dialihkan ke server B atau C. Best practice-nya jumlah node server harus ganjil, bisa 3, 5, 7, atau seterusnya. Elemen ini wajib ada pada sistem terdistribusi. Tanpa elemen ini berarti sistem database kita bukan sistem terdistribusi.
CA Database
Kombinasi CA artinya database tersebut memiliki elemen Consistency & Availability tapi mengorbankan Partition Tolerance. Contohnya adalah database tradisional kayak MySql, PostgreSql, atau sejenisnya yang memiliki satu node server. Database tersebut memiliki elemen Consistency karena servernya cuma satu sehingga antara write & read datanya udah pasti linear, apa yang di-commit itu lah yang dibaca. Database tersebut memiliki elemen Availability karena servernya cuma satu, selama masih nyala dia akan selalu memberikan response. Database tersebut ga memiliki elemen Partition Tolerance juga karena servernya cuma satu, apabila ada gangguan maka sistemnya langsung down.
Meskipun begitu, bukan berarti database tersebut ga ada toleransi terhadap gangguan. Database tradisional punya konsep Single Master Replication. Misalkan ada 3 server MySql. Satu server diantaranya berperan sebagai Master yang bertugas menulis data dan mencatatnya ke dalam Binlog. Dua server lainnya berperan sebagai Slave yang bertugas membaca data dari Binlog Master dan melayani request untuk query data. Jadi, antara read dan write servernya dibedain. Dengan begini ketika salah satu server Slave mati, maka read masih bisa dilakukan pada server Slave satunya lagi dan write tetap bisa dilakukan pada server Master. Masalahnya, jika yang mati adalah server Master, meskipun 2 server Slave lainnya masih nyala maka sistemnya ga bisa beroperasi😱. Oleh karena itu, database tradisional tetap ga bisa Partition Tolerance seutuhnya saat ada gangguan pada server Master.
Ini cocok untuk aplikasi yang datanya ga boleh bermasalah dan responsenya cepat, tapi siap dengan risiko kalau ada gangguan sistem langsung down. Contohnya aplikasi pada umumnya, by default aplikasi itu responsenya harus cepat dan data transaksinya ga boleh ada yang salah, tapi kalau ada gangguan ya apa boleh buat🙄. Sebagian besar aplikasi menggunakan database ini selama belum ada kebutuhan khusus untuk menggunakan database jenis lain.
CP Database
Kombinasi CP artinya database tersebut memiliki elemen Consistency & Partition Tolerance tapi mengorbankan Availability. Contohnya adalah CockroachDB yang menggunakan konsep Leader-Follower Replication, salah satu server berperan sebagai Leader yang menerima & mendistribusikan data dan yang lainnya berperan sebagai Follower yang menerima distribusi data dari Leader. Database tersebut memiliki elemen Consistency karena setiap data ditulis, Leader akan mendistribusikannya ke Follower secara synchronous dan hanya akan commit data jika Follower menerima datanya agar data write & read linear. Database tersebut memiliki elemen Partition Tolerance karena meskipun ada gangguan sebagian, baik itu Leader maupun Follower, maka system tetap bisa beroperasi. Database tersebut ga memiliki elemen Availability karena jika mayoritas server ada gangguan, misalkan 2 dari 3 server mati, maka server yang masih nyala ga bisa memberikan response.
Database ini bukan berarti tanpa Availability sama sekali. Database akan selalu memberikan response selama mayoritas server masih nyala walaupun ada tambahan latency pada response sepersekian millisecond karena butuh sinkronisasi ke server lain. Ketika yang mati adalah Leader maka akan terjadi Majority Quorum, yaitu proses menunjuk salah satu Follower yang masih nyala untuk naik pangkat jadi Leader yang baru menggantikan Leader yang lama dengan syarat mayoritas server masih nyala. Itu yang membedakannya dengan Single Master Replication pada database tradisional. Jika saat Majority Quorum jumlah server yang mati lebih banyak daripada yang nyala, maka sistem ga bisa memberikan response. Tujuannya untuk menjaga data agar aman dari masalah. Misalkan ada 3 server: server A jadi Leader, dan server B & C jadi Follower. Lalu server A mati dan server B naik jadi Leader, serta server C masih jadi Follower. Jika server C mati, maka server B ga boleh memberikan response meskipun dia Leader. Jika server B masih melayani input data, misalnya ada input data produk dengan nama "Susu" lalu kemudian ikut mati, maka ketika server A & C nyala kembali mereka ga tau kalau di server B ada data "Susu"😱. Itu yang dicegah oleh CP Database sehingga mengorbankan Availability.
Ini cocok untuk aplikasi yang harus aman dari gangguan server sebagian dan datanya ga boleh bermasalah, tapi kecepatan bukan hal yang utama. Contohnya aplikasi perbankan, aplikasinya harus minim gangguan dan data transaksinya ga boleh ada yang salah, tapi saat aplikasinya lemot dikit ga ngaruh. Yang penting data transaksinya aman🔐.
AP Database
Kombinasi AP artinya database tersebut memiliki elemen Availability & Partition Tolerance tapi mengorbankan Consistency. Contohnya adalah Cassandra. Database tersebut memiliki elemen Availability karena setiap data ditulis server akan segera mengembalikan response. Database tersebut memiliki elemen Partition Tolerance karena meskipun server kena gangguan sebagian maka system tetap beroperasi. Database tersebut ga memiliki elemen Consistency karena ada risiko antara write & read datanya ga linear.
Walaupun begitu, AP Database memiliki sedikit elemen Consistency. Ini dikenal dengan Eventual Consistency, yaitu saat write system akan berusaha agar datanya linear lewat distribusi data secara asynchronous, tapi ada kemungkinan data delay pada server lain dan ada kemungkinan Lost Updates ketika lebih dari satu request mengubah data yang sama secara serentak. Ga ada Isolasi data yang kuat. Database ini menganut konsep Masterless Replication. Ga ada status Master atau Leader di sini, semuanya setara. Server manapun boleh mewakili server lain untuk menulis data secara bergantian. Setelah data ditulis, server langsung mengembalikan response dan mendistribusikan data secara asynchronous ke server lain tanpa menambah latency pada response. Ini dikenal dengan Gossip Protocol, server akan menggosipkan data yang ia simpan ke server lain di belakang layar. Itu yang membedakannya dengan CP Database. Hanya saja, konsep ini mengorbankan Consistency. Misalkan ada 3 server: A, B, dan C. Ketika server A & B mati, maka semua proses akan dilayani oleh server C. Masalahnya, jika server C menyimpan data baru seperti jumlah viewer sebanyak 500 orang dan kemudian server C mati, lalu server A & B nyala kembali, maka server A & B ga tahu jumlah viewer saat ini dan kembali menghitungnya dari 0. Misalkan kemudian server A & B udah ga gangguan lagi dan menyimpan data jumlah viewer sebanyak 300, lalu server C nyala lagi, maka server C akan menyingkronkan datanya dengan data terbaru, yaitu data 300 viewer dari server A & B. Data 500 viewer di server C sebelumnya akan hilang begitu saja😱. Di sini berlaku konsep Last Write Wins, server terakhir yang menulis data yang menang.
Ini cocok untuk aplikasi yang butuh response cepat dan tahan gangguan, tapi saat datanya salah dikit ga ngaruh. Contohnya aplikasi sosial media, aplikasinya jarang down dan responsenya sangat cepat, tapi ga akan menimbulkan masalah besar saat datanya ga linear. Misalkan ada post yang di-like 1023 orang, bisa aja di list likenya kalau dihitung cuma 987 orang. Jarang banget ada orang yang ngecekin satu-satu siapa aja yang nge-like dari A sampai Z. Kurang kerjaan kalau ada😆.
P Database
Kebanyakan database NoSql itu P doang, malah kayak orang ngirim WhatsApp😅. Ga banyak database NoSql yang mutlak CP atau mutlak AP. Contohnya MongoDb, itu sebenarnya database yang "mirip" CP, tapi bukan CP seutuhnya. MongoDb menggunakan konsep Leader-Follower kayak CP Database. Namun, by default Read Concern di MongoDb itu Local, masih ada kemungkinan data yang dibaca adalah data usang sebelum commit terbaru dan ga linear. Itu dikonfirmasi dari dokumentasi MongoDb itu sendiri. MongoDb hanya jadi CP tulen jika Write Concern dan Read Concern di-set jadi Majority.
Redis juga sama, ini sebenarnya "mirip" AP, tapi bukan AP seutuhnya. Setelah data ditulis, server langsung memberikan response dan distribusi data dilakukan secara asynchronous di belakang layar kayak AP Database. Namun, Redis masih menganut konsep Leader-Follower, di mana salah satu server akan berperan sebagai Leader untuk menulis data & mendistribusikannya, lalu server lainnya berperan jadi Follower. Datanya ada kemungkinan ga linear karena distribusinya secara asynchronous dan ada kemungkinan ga bisa ngasih response karena saat Leader mati system jadi ga bisa write sampai Leadernya nyala lagi atau ada Leader baru. Dibilang CA bukan, dibilang AP juga bukan, dibilang CP juga udah pasti bukan🤭.
Beberapa database ada opsi yang membuat Consistency dan Availability bisa diutak-atik sesuai kebutuhan seperti Read Concern dan Write Concern di MongoDb. Cassandra by default adalah AP Database dengan config Consistency Level ONE. Namun config ini bisa diubah agar lebih linear jadi QUORUM atau ALL sehingga jadi ga AP lagi. Redis juga bisa diatur agar lebih linear dengan membuatnya sync antar server saat menulis data. Tapi tentu saja itu akan bikin responsenya jadi lebih lambat.
Verdict
Konsep CAP Theorem ini sedang populer di era distribusi system. CA Database itu artinya sistem database kita bukan sistem terdistribusi karena ga ada elemen Partition Tolerance di dalamnya. Namun, untuk kebutuhan data transaksi by default CA Database masih jadi pilihan utama selama belum ada kebutuhan spesifik. CP Database atau AP Database itu hanya opsional jika benar-benar dibutuhkan. Itu karena tradisional database cukup simple dan sudah cukup untuk melayani kebutuhan-kebutuhan database pada umumnya. CP Database cocok untuk fitur-fitur aplikasi kayak perbankan, sedangkan AP Database cocok untuk fitur-fitur aplikasi kayak sosial media. Aplikasi jaman sekarang mulai menggunakan lebih dari satu jenis database untuk fitur tertentu secara spesifik. Sebagian besar database NoSql memiliki elemen Partition Tolerance, tapi ga semuanya mutlak disebut AP Database atau CP Database. Beberapa database juga memiliki konfigurasi untuk mengatur Consistency Level sehingga kategori database antara CP dan AP jadi samar-samar. Ini yang bikin banyak orang yang ga baca dokumentasinya sering salah kaprah kemakan marketing🤭.