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 Consitency, Availability, dan Partition Tolerance.
Consistency
Consistency artinya data yang dibaca adalah data terakhir yang di-commit di database. Ini beda dengan makna Consistency pada ACID di mana Consistency 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. Mungkin biar singkatannya keren kali ya, kalau disingkat jadi LAP kayak kurang enak kedengarannya🤭.
Availability
Availability artinya selama servernya masih berfungsi maka database wajib memberikan response. Di sini ga ada jaminan data yang diberikan itu adalah data terbaru atau bukan. Bisa saja data yang baru diinput adalah "XYZ" tapi saat dibaca data "XYZ" tersebut belum muncul. Bisa jadi datanya delay, baru muncul setelah beberapa saat kemudian. Bisa juga malah datanya ketimpa sama input 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 terganggu💪. Pada elemen ini artinya system memiliki lebih dari satu node server agar tahan gangguan. Jika sebagian server kena gangguan ga masalah karena bisa dihandle server lain yang ga kena gangguan. Best practice-nya jumlah node server harus ganjil, bisa 3, 5, 7, atau seterusnya. Selama mayoritas server masih nyala maka system harus tetap beroperasi. Elemen ini jadi yang paling wajib di antara 3 elemen CAP pada sistem terdistribusi. Tanpa elemen ini berarti sistem database kita bukan sistem terdistribusi.
CA Database
Kombinasi CA artinya database tersebut datanya linear antara write & read dan servernya akan selalu memberikan response selama masih berfungsi, tapi sistemnya ga bisa beroperasi ketika server ada gangguan. Contohnya adalah tradisional database kayak MySql, PostgreSql, atau sejenisnya yang memiliki satu node server. Database tersebut memiliki elemen Consistency karena servernya cuma satu sehingga ga perlu mendistribusikan datanya ke server lain saat ditulis, apa yang di-commit itu lah yang dibaca. Database tersebut memiliki Availability karena servernya cuma satu, selama masih nyala dia akan selalu memberikan response. Database tersebut ga memiliki Partition Tolerance karena servernya cuma satu, apabila ada gangguan ya sudah pasti ga akan bisa beroperasi.
Meskipun begitu, bukan berarti database tersebut ga ada toleransi sama sekali terhadap gangguan sistem. Database tersebut bisa kita rancang menggunakan konsep Master-Slave dengan Single Master Replication. Misalkan ada 3 server MySql. Satu server diantaranya akan berperan sebagai Master yang bertugas menulis data pada sistem dan mencatatnya ke dalam Binlog. Dua server lainnya akan 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, tradisional database masih tetap disebut CA Database karena ga bisa Partition Tolerance seutuhnya kalau ada gangguan pada server Master.
Keunggulan dari database ini adalah datanya linear dan responsenya cepat. Ini cocok untuk aplikasi yang butuh response cepat dan datanya ga boleh bermasalah, tapi siap dengan risiko kalau servernya gangguan sistem langsung down. Contohnya aplikasi yang simple-simple aja kayak aplikasi pada umumnya, responsenya 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 datanya linear antara write & read dan systemnya tetap bisa beroperasi ketika sebagian server terganggu, tapi ketika mayoritas servernya gangguan maka server ga bisa memberikan response. Contohnya adalah CockroachDB yang menggunakan konsep Leader-Follower Replication. Database tersebut memiliki elemen Consistency karena setiap data ditulis, salah satu server akan bertindak sebagai Leader, lalu mendistribusikannya ke server lain yang bertindak sebagai Follower secara synchronous dan hanya akan commit data jika Follower menerima datanya sehingga data write & read linear. Database tersebut memiliki elemen Partition Tolerance karena meskipun server gangguan sebagian, baik itu Leader maupun Follower, maka system tetap bisa beroperasi. Database tersebut ga memiliki elemen Availability karena jika mayoritas server gangguan, misalkan 2 dari 3 server mati, maka database ga bisa memberikan response.
Database ini bukan berarti tanpa Availability sama sekali. Mereka membagi data menjadi beberapa chunk dan tiap chunk punya Leader masing-masing. Ketika yang mati adalah Leader maka akan terjadi Majority Quorum, yaitu proses menunjuk salah satu Follower yang masih nyala untuk naik pangkat jadi Leader menggantikan Leader yang lama. Itu yang membedakannya dengan Single Master Replication pada database tradisional. Database akan memberikan response selama mayoritas server masih nyala. Yang jadi masalah hanyalah saat Majority Quorum ketika jumlah server yang mati lebih banyak daripada yang nyala, baru lah sistem ga bisa memberikan response. Tujuannya untuk menjaga konsistensi data. 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 beroperasi meskipun dia Leader. Jika server B masih melayani input data, misalnya input data produk dengan nama "Susu" lalu kemudian ikut mati, maka ketika server A dan C nyala kembali mereka jadi ga tau kalau di server B ada data "Susu"😱. Anomali seperti itu yang dicegah oleh CP Database sehingga mengorbankan Availability ketika mayoritas server mati.
Keunggulan dari database ini adalah datanya linear dan tahan gangguan dengan risiko ga secepat jenis database lainnya. Ini cocok untuk aplikasi yang aman dari gangguan server sebagian dan datanya ga boleh bermasalah, tapi kecepatan aplikasi bukan hal yang utama. Contohnya aplikasi perbankan, aplikasinya sebisa mungkin 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 akan selalu memberikan response selama server masih berfungsi dan akan tetap beroperasi meskipun sebagian server terganggu, tapi ga menjamin data yang diberikan adalah data commit terbaru sehingga ga linear antara write & read. Contohnya adalah Cassandra yang menggunakan konsep Masterless Replication. Database tersebut memiliki elemen Availability karena setiap data ditulis salah satu server akan menerima dan langsung memberikan response, ga peduli ada berapa server lain yang masih nyala. Database tersebut memiliki elemen Partition Tolerance karena meskipun server gangguan sebagian, maka system tetap beroperasi karena ga ada yang jadi Master di sini. Database tersebut ga memiliki elemen Consistency karena proses distribusi data ke server lain saat data ditulis dilakukan secara asynchronous tanpa perlu tunggu konfirmasi dari server lain sehingga ada risiko data hilang dan antara write & read datanya ga linear.
Walaupun begitu, AP Database memiliki sedikit elemen Consistency, tapi ga seutuhnya. Ini dikenal dengan Eventual Consistency, yaitu system akan berusaha agar datanya linear, tapi ga ada jaminannya, ada kemungkinan delay dan ada kemungkinan Lost Updates ketika ada 2 request mengubah data yang sama secara bersamaan. 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 memberikan response dan mendistribusikan data secara asynchronous ke server lain. Ini dikenal dengan Gossip Protocol, server bergantian menerima data dan menggosipkan data yang ia terima 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 dan 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 dan B nyala kembali, maka server A dan B ga tahu jumlah viewer saat ini dan kembali menghitungnya dari 0. Misalkan kemudian server A dan B udah ga gangguan lagi dan sudah konsisten 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 dan B. Data 500 viewer di server C sebelumnya akan hilang begitu saja😱. Mereka menerapkan konsep Last Write Wins, server terakhir yang menulis data yang menang.
Keunggulan dari database ini adalah prosesnya cepat dan aman dari gangguan server sebagian dengan risiko data ga linear. Ini cocok untuk aplikasi yang tahan gangguan dan responsenya cepat, 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 konsisten kayak komentar yang kita tulis tiba-tiba hilang, atau jumlah like yang ga konsisten. Misalkan ada post yang di-like 1000 orang, ga bakal ada juga orang yang bakal ngecekin satu-satu siapa aja yang nge-like dari A sampai Z. Kurang kerjaan kalau ada😅.
P Database
Kebanyakan database NoSql itu P doang. Ga banyak database NoSql yang mutlak CP atau AP. Mungkin kalau mereka marketingnya sebagai P Database doang kurang keren kali ya😅. Kayak 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 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 seperti AP Database tanpa harus menunggu konfirmasi dari mayoritas server lainnya. 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 seperti CP Database. Datanya ada kemungkinan ga linear karena distribusinya secara asynchronous dan ada kemungkinan ga available karena saat Leader mati jadi ga bisa write sampai ada Leader baru. Dibilang AP bukan, dibilang CP juga udah pasti bukan🤭. Beberapa database ada opsi yang membuat Consistency dan Availability ini bisa diotak-atik sesuai kebutuhan. Kayak Cassandra, by default itu AP Database dengan config Consistency Level ONE. Config ini bisa diubah agar lebih strict jadi QUORUM atau ALL. Redis juga bisa diatur agar lebih konsisten dengan membuatnya sync antar Replica saat menulis data. Tentu saja itu akan bikin prosesnya 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 Databasa 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 menggunakan lebih dari satu jenis database untuk kebutuhan tertentu. 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 doang🤭.