Belajar Debezium - Konsep Dasar & Arsitektur Debezium

#Pendahuluan

Episode 1 memberi kalian alasan mengapa CDC dan Debezium lahir. Sekarang saatnya membongkar mesinnya. Episode 2 ini membahas bagaimana Debezium bekerja dari sisi arsitektur: siapa yang menjalankan connector, ke mana event dikirim, bagaimana posisi baca dicatat, dan bagaimana data dibungkus sebelum sampai ke Kafka.

Tiga komponen kunci yang akan kalian temui adalah connector (logika pengambilan perubahan), Kafka Connect (runtime yang mengeksekusi connector), dan Kafka topics (tujuan akhir event). Memahami ketiganya sejak awal akan membuat debugging di episode-episode berikutnya terasa jauh lebih mudah.

#Arsitektur Debezium dari Tinggi ke Rendah

#Connector, Kafka Connect, dan Kafka Topics

Satu connector mewakili satu sumber database. Saat connector dijalankan, dia dipecah menjadi satu atau lebih tasks yang berjalan di dalam worker Kafka Connect. Setiap task membaca perubahan dari database lalu memproduksi event ke topic Kafka bernama topic.prefix.database.table.

database → Debezium connector → Kafka Connect worker → Kafka topics
                                                          ↓
                                        consumer groups + downstream systems

Karena Debezium hidup di dalam Kafka Connect, seluruh infrastruktur Kafka Connect ikut menentukan perilakunya: tempat offset disimpan, frekuensi commit, dan converter yang dipakai. Contoh properti worker yang akan sering kalian lihat:

bootstrap.servers: kafka:9092
group.id: 1
key.converter: org.apache.kafka.connect.json.JsonConverter
value.converter: org.apache.kafka.connect.json.JsonConverter
offset.storage.topic: connect-offsets
config.storage.topic: connect-configs
status.storage.topic: connect-status

Perhatikan bahwa Kafka Connect butuh tiga topic internal: config, offset, dan status. Topic inilah yang membuat worker dalam satu cluster bisa berbagi konfigurasi, posisi baca, dan status antar connector.

#Peran Kafka Topics sebagai Output

Setiap perubahan satu baris menghasilkan satu event yang dikirim ke satu topic berdasarkan aturan penamaan topic.prefix ditambah nama database dan tabel. Jika topic.prefix kalian dbserver1, maka tabel customers di database inventory akan menghasilkan topic dbserver1.inventory.customers. Konvensi ini penting karena konsumen bisa memprediksi nama topic tanpa membaca konfigurasi.

#Bagaimana Debezium Membaca Log Perubahan

Debezium menerapkan pendekatan log-based capture: ia tidak mengeksekusi query ulang, melainkan mengurai catatan perubahan yang sudah ditulis database. Setiap database memakai mekanisme yang berbeda:

Dari log yang berisi fisik tersebut, Debezium menyusun ulang perubahan logis — baris mana yang bertambah, berubah, atau hilang, beserta nilai sebelum dan sesudahnya. Inilah keunggulan utama CDC: detail perubahan diperoleh langsung dari database, tanpa menyuntikkan beban tambahan.

#Offset, Heartbeat, dan Snapshot

#Offset Storage dan Recovery

Agar tidak membaca ulang data yang sama, Debezium menyimpan offset — penanda posisi terakhir di log database — ke dalam topic offset Kafka Connect. Saat worker restart, connector melanjutkan dari posisi terakhir, bukan dari awal. Inilah yang membuat pipeline CDC toleran terhadap restart:

docker exec -it kafka /opt/kafka/bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

Pada daftar tersebut kalian akan melihat connect-offsets, connect-configs, dan connect-status di samping topic data. Offset disimpan sebagai byte terkompresi, jadi jangan berharap bisa membaca isinya sebagai teks biasa.

#Heartbeat dan Snapshot

Snapshot adalah mekanisme Debezium membaca seluruh data yang sudah ada sebelum memulai streaming. Nilai snapshot.mode menentukan perilakunya: initial mengambil snapshot lalu lanjut streaming, sedangkan initial_only berhenti setelah snapshot selesai. Sementara itu heartbeat adalah event periodik yang dikirim agar posisi baca tetap tercatat saat database sepi, sehingga lag tidak melonjak ketika lalu lintas kembali ramai:

heartbeat.interval.ms: 5000
snapshot.mode: initial
snapshot.fetch.size: 1024

Dengan heartbeat.interval.ms: 5000, Debezium mengirim penanda setiap lima detik meskipun tidak ada perubahan data. Ini menjaga offset tetap segar dan memudahkan monitoring di episode 7.

#Schema Registry dan Format Payload

Event Debezium bukan sekadar nilai data mentah. Secara default event dibungkus menjadi dua bagian: schema yang mendeskripsikan struktur, dan payload yang berisi nilai sebenarnya. Formatnya dikendalikan oleh converter yang dipasang di worker.

Tanpa schema registry, kalian memakai JSON converter bawaan. Untuk lingkungan produksi, banyak tim beralih ke Avro atau Protobuf yang dibantu schema registry untuk mengelola versi struktur data:

key.converter: io.confluent.connect.avro.AvroConverter
value.converter: io.confluent.connect.avro.AvroConverter
key.converter.schema.registry.url: http://schema-registry:8081
value.converter.schema.registry.url: http://schema-registry:8081

Dengan schema.registry.url, setiap event membawa referensi ID skema, bukan skema lengkap. Payload menjadi lebih kecil, dan konsumen bisa memvalidasi struktur data sebelum memprosesnya. Detail format ini akan kita bedah menyeluruh di episode 5 dan 9.

#Topic Internal Setiap Connector

Selain tiga topic internal Kafka Connect, beberapa connector Debezium memerlukan topic tambahan. Connector MySQL memakai topic schema history untuk menyimpan riwayat struktur tabel, dan connector PostgreSQL serta MongoDB memerlukan slot replikasi di sisi sumber. Topic dan slot internal ini harus dijaga sebaik topic data biasa — kehilangannya bisa memaksa connector melakukan snapshot ulang dari awal.

Pastikan topic internal tidak terkena kebijakan retensi yang terlalu pendek. Jika retensi topic schema history dipangkas, connector tidak bisa lagi merekonstruksi skema lama saat offset di-reset, dan pemulihan pun gagal.

#Penutup

Episode 2 memberi kalian peta arsitektur Debezium: connector membaca transaction log, Kafka Connect mengeksekusi dan mengatur lifecycle-nya, event dikirim ke topic dengan aturan penamaan baku, offset menjaga posisi baca saat restart, snapshot mengisi data awal, dan schema registry menjaga struktur payload.

Inti yang harus dibawa pulang:

• Debezium adalah source connector yang berjalan di dalam Kafka Connect, bukan aplikasi mandiri.
• Setiap event dikirim ke topic dengan pola topic.prefix.database.table.
• Offset disimpan di topic internal Kafka Connect sehingga restart tidak kehilangan posisi baca.
• Snapshot mengisi data awal; heartbeat menjaga offset tetap segar saat database sepi.
• Format payload ditentukan oleh converter, dan Avro atau Protobuf memerlukan schema registry.

Di episode 3 selanjutnya kita akan melakukan instalasi dan menyiapkan connector pertama: menjalankan MySQL sebagai sumber, mendaftarkan connector Debezium lewat REST API, lalu memverifikasi topic output dan pesan CDC pertama. Siapkan Docker yang sudah diverifikasi di episode 0.