Belajar Debezium - Payload Format & Schema Evolution

#Pendahuluan

Setiap perubahan yang ditangkap Debezium dibungkus menjadi event dengan struktur yang konsisten di semua connector. Konsumen yang memahami struktur ini bisa menafsirkan perubahan apa pun tanpa harus tahu database asalnya. Episode 5 membedah struktur tersebut, lalu membandingkan tiga format serialisasi utama dan cara menjaga skema tetap berevolusi dengan aman.

Memahami anatomi event bukan sekadar teori: keputusan seperti memakai JSON atau Avro, mengatur mode representasi desimal, dan memilih aturan kompatibilitas schema registry akan menentukan apakah pipeline kalian bertahan bertahun-tahun atau hancur saat satu kolom ditambahkan.

#Anatomi Event Debezium

Event Debezium terdiri dari dua blok besar: schema dan payload. Payload adalah bagian yang paling sering dibaca:

Contoh event create di MySQL

{
  "payload": {
    "before": null,
    "after": {
      "id": 1004,
      "first_name": "Anne",
      "last_name": "Kretchmar",
      "email": "annek@noanswer.org"
    },
    "source": {
      "version": "3.0.0.Final",
      "connector": "mysql",
      "name": "dbserver1",
      "db": "inventory",
      "table": "customers",
      "server_id": 223344,
      "ts_ms": 1710000000000
    },
    "op": "c",
    "ts_ms": 1710000000123
  }
}

Bidang penting di dalam payload:

before: nilai baris sebelum perubahan, null untuk insert.
after: nilai baris setelah perubahan, null untuk delete.
source: metadata asal perubahan — connector, database, tabel, dan koordinat log.
op: jenis operasi.
ts_ms: waktu event dibuat.

Nilai op memiliki kode standar:

Kode	Arti
`c`	Create / insert
`u`	Update
`d`	Delete
`r`	Read / hasil snapshot
`t`	Truncate

Dengan kombinasi before dan after, konsumen bisa merekonstruksi perubahan lengkap: siapa yang berubah, dari nilai apa, ke nilai apa.

#Format Payload: JSON versus Avro versus Protobuf

Event Debezium bisa diserialisasi dalam tiga format utama:

Aspek	JSON	Avro	Protobuf
Keterbacaan	Sangat baik	Sedang	Sedang
Ukuran event	Besar	Kecil	Paling kecil
Validasi skema	Manual	Otomatis	Otomatis
Ekosistem	Universal	Confluent, Apache	Cloud-native

JSON paling mudah dimulai dan cocok untuk prototyping, tetapi setiap event membawa skema penuh sehingga boros bandwidth. Avro dan Protobuf menyerahkan deskripsi skema ke schema registry, membuat event kecil dan tervalidasi.

#Integrasi dengan Schema Registry untuk Evolusi Skema

Agar Avro atau Protobuf bekerja, setiap worker harus menunjuk ke schema registry:

Converter Avro di worker

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

Saat tabel berubah — misalnya kolom email ditambah — Debezium membuat versi skema baru. Schema registry menyimpan riwayat versi dan menegakkan aturan kompatibilitas sebelum skema baru disetujui. Konsumen lama yang hanya butuh kolom lama tetap bisa membaca event baru selama skema tetap kompatibel.

#Best Practice Field Mapping dan Konversi Skema

Tipe data database tidak selalu punya padanan langsung di format event. Debezium menyediakan properti untuk mengendalikan konversi:

Mode konversi tipe data

{
  "decimal.handling.mode": "double",
  "interval.handling.mode": "string",
  "time.precision.mode": "adaptive",
  "binary.handling.mode": "bytes"
}

Beberapa pedoman yang perlu diperhatikan:

decimal.handling.mode dengan nilai precise menjaga presisi penuh namun menghasilkan representasi byte; double lebih sederhana tapi berisiko presisi.
interval.handling.mode dengan string mempertahankan makna interval PostgreSQL secara eksplisit.
Hindari mengubah mode konversi di connector yang sudah berjalan, karena skema event akan berubah dan bisa melanggar kompatibilitas.

Warning

Mengubah mode konversi tipe data pada connector yang sudah produksi akan mengubah struktur event dan memengaruhi seluruh konsumen. Uji di staging terlebih dahulu dengan skema baru.

#Penutup

Episode 5 membuka kotak hitam event Debezium: payload dengan before, after, source, op, dan ts_ms, kode operasi standar, perbandingan format serialisasi, peran schema registry dalam evolusi skema, dan kontrol konversi tipe data.

Inti yang harus dibawa pulang:

Payload Debezium selalu terdiri dari before, after, source, op, dan ts_ms.
op menentukan jenis operasi: c, u, d, r, atau t.
JSON mudah dibaca tapi boros; Avro dan Protobuf lebih ringkas dan tervalidasi.
Schema registry menyimpan versi skema dan menegakkan aturan kompatibilitas.
Mode konversi tipe data harus stabil untuk menjaga kompatibilitas event.

Di episode 6 selanjutnya kita akan membahas filtering, routing, dan topic design — membatasi tabel yang di-capture, merutekan event ke topic berbeda, strategi penamaan topic dan partitioning, serta penggunaan transforms.