Belajar Debezium - Sejarah, Latar Belakang & Mengapa CDC

#Pendahuluan

Episode 0 sudah memastikan environment kalian siap. Sekarang saatnya memahami mengapa Debezium ada. Episode 1 ini menjawab tiga pertanyaan besar: bagaimana cara menangkap data yang berubah dari masa ke masa, dari mana Debezium berasal, dan mengapa change data capture menjadi standar baru untuk data engineering.

Banyak orang mulai memakai Debezium hanya karena mengikuti tutorial, padahal memahami latar belakangnya jauh lebih berharga. Dengan mengetahui masalah yang diselesaikan, kalian akan lebih mudah memutuskan kapan memakai CDC, kapan tidak, dan bagaimana memposisikannya dalam arsitektur data. Mari kita mulai dari awal cerita.

#Evolusi Pengolahan Data: dari Batch ETL ke CDC

#Era Batch ETL

Selama bertahun-tahun, aliran data antar sistem digerakkan oleh batch ETL: data diekstrak dari sumber secara periodik — misalnya setiap malam — lalu ditransformasi dan dimuat ke target. Pola ini sederhana dan bisa diprediksi, tapi punya kelemahan besar: latensi bisa mencapai jam, data tidak pernah benar-benar terkini, dan prosesnya boros karena mengolah ulang seluruh dataset padahal hanya sebagian kecil yang berubah.

Contoh paling umum adalah job cron yang menjalankan query agregat terhadap tabel transaksi lalu menulis hasilnya ke data warehouse. Selama kebutuhan analisis tidak menuntut data real-time, pola ini cukup nyaman. Namun begitu organisasi ingin mengambil keputusan berdasarkan data yang segar, dinding keterbatasannya segera terlihat.

#Era Polling-Based Ingestion

Untuk mengurangi latensi, banyak tim beralih ke polling: aplikasi bertanya ke database secara berkala, apakah ada baris baru sejak query terakhir. Caranya dengan kolom updated_at atau kenaikan id. Pendekatan ini lebih responsif, tapi rapuh: kolom tidak selalu ada, perubahan yang menghapus baris tidak terdeteksi, beban query terus menerus menekan database produksi, dan logika polling menumpuk di setiap aplikasi.

Pola query-nya biasanya menyerupai ini:

Pola query polling

SELECT id, name, email
FROM customers
WHERE updated_at > ?
ORDER BY updated_at ASC
LIMIT 1000

Perhatikan bahwa pola di atas bergantung pada kolom updated_at yang di-maintain secara disiplin oleh aplikasi. Kalau ada path penulisan yang lupa meng-update kolom itu, perubahan hilang dari radar polling. Penghapusan baris juga tidak terdeteksi sama sekali kecuali memakai soft delete, sehingga data yang sudah dihapus tetap dianggap ada di sistem downstream.

#Lahirnya Change Data Capture

Change data capture (CDC) menawarkan jawaban yang lebih elegan: alih-alih menebak perubahan dengan query, CDC membaca catatan perubahan yang memang sudah dibuat database di transaction log-nya. Perubahan ditangkap saat itu juga, dalam urutan aslinya, tanpa menambah beban query ke database sumber. Debezium adalah salah satu implementasi CDC paling populer untuk pendekatan ini.

batch ETL (latensi jam)
  └── polling (latensi detik, query tambahan)
        └── CDC (latensi milidetik, membaca transaction log)

#Sejarah dan Perjalanan Debezium

#Awal Mula di Red Hat

Debezium pertama kali dikembangkan sekitar tahun 2016 oleh para engineer Red Hat, terinspirasi dari alat-alat CDC awal seperti Maxwell dan alat internal Red Hat untuk menangkap perubahan data. Nama Debezium diambil dari istilah bahasa Jerman yang berarti landasan atau sambungan — tepat untuk alat yang menjembatani database dan sistem lain.

#Dari Open Source Menjadi Proyek Apache

Perjalanan Debezium berlanjut dengan cepat:

• 2016: Debezium dirilis sebagai project open source oleh Red Hat.
• 2023: masuk ke dalam Apache Incubator, menandai keseriusan governance komunitasnya.
• 2025: resmi menjadi top-level project di Apache Software Foundation.
• 2025-2026: rilis 3.x dengan dukungan penuh terhadap Kafka terbaru dan mode KRaft.

Sejak menjadi proyek Apache, ekosistem Debezium tumbuh pesat: puluhan connector, dokumentasi yang rapi, dan komunitas aktif yang terus memperbaiki kualitas rilis. Versi 3.x yang kalian pakai di episode 0 adalah hasil dari perjalanan panjang tersebut.

#Peran Debezium dalam Ekosistem Event Streaming

Debezium mengubah database menjadi event source. Sekali perubahan terjadi di database, Debezium mengubahnya menjadi event terstruktur dan memproduksinya ke Kafka. Dari sana, seluruh ekosistem bisa mengkonsumsi:

• Aplikasi lain membaca event untuk sinkronisasi data secara real-time.
• Stream processors seperti ksqlDB dan Kafka Streams memprosesnya langsung.
• Sink connector mengalirkannya ke Elasticsearch, data warehouse, atau data lake.
• Data scientists mengkonsumsi event untuk analytics dan machine learning.

Posisi ini membuat Debezium menjadi landasan antara database transaksional dan dunia event streaming — peran yang persis dengan arti namanya.

#CDC versus Polling versus Batch ETL

Agar keputusan arsitektur lebih mudah, bandingkan ketiga pendekatan ini:

Dari tabel ini terlihat jelas: CDC unggul di hampir semua dimensi ketika kebutuhan utamanya adalah data yang selalu terkini. Namun batch ETL tetap relevan untuk transformasi berat dan kebutuhan historis, jadi ketiganya sering hidup berdampingan dalam satu arsitektur.

#Use Case yang Melatarbelakangi Debezium

Debezium lahir untuk menyelesaikan masalah-masalah nyata seperti ini:

• Database replication: menyalin data dari database utama ke read replica atau database lain secara real-time.
• Analytics pipeline: mengalirkan perubahan data ke data warehouse tanpa menunggu batch malam.
• Auditing: menyimpan jejak lengkap setiap perubahan — siapa, kapan, dan bagaimana data berubah.
• Materialized views: membangun tampilan data yang diperbarui otomatis dari aliran perubahan.
• Microservices data sync: menjaga data antar microservice tetap sinkron lewat event, bukan lewat query lintas layanan.

#Penutup

Episode 1 memberi kalian konteks: pengolahan data berevolusi dari batch ETL yang lambat, lewat polling yang rapuh, menuju CDC yang membaca transaction log secara real-time. Debezium lahir di Red Hat sekitar 2016 dan kini menjadi top-level project Apache dengan rilis 3.x yang sehat.

Inti yang harus dibawa pulang:

• CDC membaca transaction log database, sehingga latensinya milidetik dan beban ke sumbernya rendah.
• Debezium lahir di Red Hat sekitar 2016 dan menjadi proyek Apache pada 2025.
• CDC unggul dalam deteksi delete, urutan kejadian, dan integritas transaksi.
• Debezium mengubah database menjadi event source untuk seluruh ekosistem streaming.
• Use case utama: replication, analytics, auditing, materialized views, dan microservices sync.

Di episode 2 selanjutnya kita akan membahas konsep dasar dan arsitektur Debezium — bagaimana connector membaca log perubahan database, peran Kafka Connect dan Kafka topics, mekanisme offsets, heartbeats, dan snapshot, serta hubungannya dengan schema registry dan format payload. Ini adalah fondasi arsitektural yang akan menemani seluruh series.