Designing Data-Intensive Applications
oleh Martin Kleppmann
Di Balik Setiap Aplikasi Modern, Ada Pertaruhan yang Jarang Disadari
Bayangkan Anda baru saja transfer uang lewat aplikasi bank. Anda lihat saldo berkurang, notifikasi muncul, semua terasa instan dan pasti. Tapi di balik layar, permintaan Anda baru saja melewati belasan lompatan: masuk ke load balancer, diproses satu dari puluhan server yang identik, dicatat ke database yang direplikasi ke tiga lokasi berbeda, dan mungkin juga dikirim lewat message queue ke sistem lain yang mencatat riwayat transaksi Anda.
Jika satu dari server itu mati di tengah proses. Jika dua replika database sempat tidak sinkron selama sepersekian detik. Jika pesan yang dikirim ke message queue terkirim dua kali karena jaringan sempat putus.
Apakah saldo Anda tetap benar?
Martin Kleppmann, peneliti di University of Cambridge yang sebelumnya membangun sistem data skala besar di LinkedIn, menghabiskan bertahun-tahun mengumpulkan jawaban atas pertanyaan semacam ini—dan menuliskannya dalam salah satu buku teknis paling dihormati satu dekade terakhir.
Ini bukan buku tentang cara pakai satu database tertentu. Ini buku tentang bagaimana data—jantung dari hampir semua aplikasi—benar-benar bekerja di balik layar, dan kenapa keputusan yang kelihatan teknis semata sebenarnya adalah keputusan tentang kepercayaan: kapan sistem boleh bilang "aman", dan kapan sebenarnya sedang berbohong.
Contoh Analogi
Bayangkan Anda dan teman sedang menulis catatan bersama di dua buku terpisah, lalu sesekali saling menyalin catatan satu sama lain lewat kurir. Kalau kurirnya cepat dan selalu berhasil, catatan kalian berdua akan selalu sama. Tapi kalau kurirnya kadang telat, kadang hilang di jalan, sesekali catatan kalian berdua akan berbeda untuk sementara waktu—dan Anda harus memutuskan: apakah itu masalah besar, atau bisa ditoleransi selama akhirnya tetap sama?
Selamat datang di dunia data-intensive systems yang sesungguhnya.
Bagian 1: Tiga Pilar yang Harus Selalu Jadi Lensa
Reliability, Scalability, Maintainability
Kleppmann membuka bukunya dengan menegaskan bahwa setiap keputusan arsitektur data seharusnya dievaluasi lewat tiga lensa ini. Reliability berarti sistem tetap bekerja benar bahkan ketika terjadi kesalahan—baik dari hardware, software, maupun manusia yang mengoperasikannya. Scalability berarti sistem punya cara masuk akal untuk menangani pertumbuhan beban, entah itu data, trafik, atau kompleksitas. Maintainability berarti sistem tetap bisa dipahami, diubah, dan dioperasikan dengan aman oleh orang-orang yang berbeda dari yang membangunnya di awal.
Kenapa Ketiganya Sering Saling Tarik-menarik
Sistem yang sangat scalable sering mengorbankan sedikit reliability demi kecepatan. Sistem yang sangat reliable sering menambah kompleksitas yang mengorbankan maintainability. Tidak ada solusi yang optimal di semua sisi sekaligus—yang ada hanya trade-off yang harus dipahami secara sadar, bukan kebetulan.
Bagian 2: Replication—Menyalin Data ke Banyak Tempat
Kenapa Data Perlu Disalin
Data direplikasi ke banyak mesin untuk dua alasan utama: supaya tetap tersedia meski satu mesin mati, dan supaya bisa dibaca dari lokasi yang lebih dekat dengan penggunanya.
Leader-Follower
Pola paling umum: satu node jadi leader yang menerima semua penulisan data, lalu menyebarkan perubahan itu ke node-node follower. Masalahnya muncul saat replication lag—follower belum sempat menerima update terbaru saat dibaca, sehingga pengguna bisa melihat data yang sudah usang.
Multi-Leader dan Leaderless
Multi-leader memungkinkan penulisan di lebih dari satu node sekaligus, cocok untuk sistem yang tersebar di banyak lokasi geografis—tapi membuka risiko konflik saat dua node menulis data yang sama secara bersamaan. Leaderless (seperti pada Dynamo-style database) menghilangkan konsep leader sama sekali, mengandalkan quorum—memastikan cukup banyak node yang setuju sebelum sebuah operasi dianggap berhasil.
“Replication lag can lead to inconsistencies that are easy to overlook in testing, but become significant problems in production.”
Bagian 3: Partitioning—Membelah Data Jadi Bagian Lebih Kecil
Kenapa Data Perlu Dibelah
Ketika data terlalu besar untuk muat di satu mesin, atau trafiknya terlalu tinggi untuk ditangani satu mesin, data dibelah jadi beberapa bagian yang disebar ke banyak mesin—masing-masing menangani sebagian dari keseluruhan data.
Partitioning by Key Range vs by Hash
Membelah berdasarkan rentang key (misalnya nama A-M di satu mesin, N-Z di mesin lain) memudahkan pencarian rentang data, tapi rawan menciptakan hot spot—satu partisi jadi jauh lebih sibuk dari yang lain kalau datanya tidak tersebar merata. Membelah berdasarkan hash dari key menyebarkan beban lebih merata, tapi mengorbankan kemampuan mencari data secara berurutan.
Rebalancing
Ketika mesin baru ditambahkan atau dihapus, data harus dipindahkan ulang antar partisi. Kleppmann menekankan pentingnya strategi rebalancing yang tidak memaksa memindahkan seluruh data sekaligus, karena itu bisa membebani sistem yang sedang berjalan secara live.
Bagian 4: Transactions dan Isolation Levels yang Sering Disalahpahami
"Pakai Transaction" Saja Tidak Cukup
Banyak developer berpikir begitu mereka membungkus operasi dalam sebuah transaction, semuanya otomatis aman. Kleppmann membongkar asumsi ini: level isolasi default di banyak database populer sebenarnya cukup lemah.
Tingkatan Isolasi
Read committed hanya menjamin Anda tidak membaca data yang belum di-commit—tapi masih membuka celah race condition tertentu. Snapshot isolation memberi Anda "potret" data yang konsisten sepanjang transaction berjalan, tapi masih bisa kebobolan pada kasus tertentu seperti write skew. Serializable adalah level paling ketat, membuat transaction seolah-olah dijalankan satu per satu secara berurutan—tapi datang dengan ongkos performa yang signifikan.
Kenapa Ini Penting
Banyak bug produksi yang sulit dilacak sebenarnya berakar dari asumsi keliru soal level isolasi yang sedang dipakai—developer mengira sistemnya lebih aman dari yang sebenarnya.
Bagian 5: Consistency, Consensus, dan Kejujuran Sebuah Sistem
Linearizability Itu Mahal
Linearizability memberi jaminan paling kuat: begitu sebuah operasi selesai, semua node lain akan langsung melihat hasil yang sama, seolah-olah hanya ada satu salinan data di dunia. Tapi menjaga jaminan ini di sistem terdistribusi datang dengan ongkos latensi dan availability yang besar.
Eventual Consistency Bukan Aib
Kleppmann menegaskan bahwa eventual consistency—di mana semua node akan akhirnya konsisten, meski butuh waktu—bukan tanda sistem yang buruk, selama konsekuensinya dipahami dan memang bisa ditoleransi oleh use case-nya.
Konsensus untuk Keputusan Kritis
Untuk kasus yang benar-benar butuh semua node sepakat pada satu keputusan (misalnya siapa yang jadi leader baru saat leader lama mati), dibutuhkan algoritma konsensus seperti Raft atau Paxos—mekanisme yang memastikan mayoritas node setuju sebelum sebuah keputusan dianggap final.
“Just because the data is technically consistent doesn't mean it's what the user wants.”
Bagian 6: Pelajaran untuk Hari Ini
1. Selalu Tanya: Reliability, Scalability, atau Maintainability yang Sedang Dikorbankan?
Setiap keputusan arsitektur data mengorbankan sesuatu. Sadari trade-off-nya sejak awal, bukan setelah insiden produksi.
2. Jangan Asumsikan Replikasi Selalu Real-Time
Desain sistem Anda dengan asumsi ada jeda antara data ditulis dan data itu terlihat di semua tempat.
3. Pahami Isolation Level Database yang Anda Pakai
Jangan asumsikan "pakai transaction" otomatis berarti aman dari semua race condition. Cek level isolasi default-nya.
4. Eventual Consistency Boleh Dipakai, Asal Sadar
Untuk data yang tidak kritikal (misalnya jumlah like, view count), eventual consistency sering jadi pilihan yang jauh lebih murah dan tetap masuk akal.
5. Pertimbangkan Unbundling Database
Sistem modern sering memisahkan tanggung jawab: satu bagian untuk penyimpanan, satu untuk pencarian, satu untuk analitik—bukan memaksa satu database menangani semuanya sekaligus.
Penutup
Martin Kleppmann tidak menawarkan satu database atau arsitektur yang "paling benar". Yang ditawarkannya adalah kerangka berpikir untuk memahami trade-off yang selalu ada di balik setiap sistem yang menyimpan dan memproses data.
Di dunia yang makin bergantung pada data—termasuk sistem AI yang haus akan data dalam jumlah besar—pemahaman mendalam soal replication, partitioning, dan consistency bukan lagi pengetahuan opsional untuk engineer senior saja. Ini fondasi yang menentukan apakah sebuah sistem benar-benar bisa dipercaya, atau hanya terlihat bekerja sampai suatu hari gagal dengan cara yang tidak terduga.
Pertanyaannya bukan apakah sistem Anda akan menghadapi kegagalan jaringan atau race condition. Pertanyaannya: apakah Anda sudah memahami konsekuensinya sebelum itu terjadi.
Tentang Buku Asli
"Designing Data-Intensive Applications" pertama terbit tahun 2017 dan sejak itu menjadi salah satu buku teknis paling direkomendasikan di industri software, terutama untuk engineer yang bekerja dengan sistem skala besar.
Martin Kleppmann adalah peneliti senior di University of Cambridge yang sebelumnya bekerja sebagai software engineer dan entrepreneur, termasuk membangun sistem data di LinkedIn. Latar belakangnya yang menggabungkan riset akademis dengan pengalaman langsung membangun sistem produksi membuat buku ini terasa sangat grounded, jarang terjebak teori tanpa konteks praktis.
Buku ini terkenal padat—setiap babnya bisa dibaca berulang kali dengan pemahaman baru setiap kali. Untuk memahami sepenuhnya detail algoritma dan studi kasus dari berbagai sistem nyata (Kafka, Cassandra, PostgreSQL, dan lainnya) yang dibahas Kleppmann, buku aslinya sangat layak dibaca. Ringkasan ini menangkap gagasan pokoknya—tapi buku utuhnya menyuguhkan kedalaman teknis yang hanya bisa didapat dengan membaca seluruh uraiannya.
Bagi siapa pun yang membangun sistem yang menyimpan dan memproses data—baik itu aplikasi kecil maupun sistem skala enterprise—buku ini adalah pengingat bahwa di balik setiap query yang terlihat sederhana, ada pertaruhan soal kepercayaan yang jarang benar-benar dipikirkan sampai semuanya terlambat.
